Request URI and TO heasder "user" part is different

[Nitin Kapoor]

Hello,

I have the scenario where the call is coming to SBC from my source UA and
then I am forwarding the same call to redirect server to route the call.

Here is the scenario.

1) Call come to my source UA and then I forwarded the call to redirect
server with below REQUEST uri.

Request-Line: INVITE
sip:***@208.70.157.43<sip%***@208.70.157.43>;user=phone
SIP/2.0
Request-URI: sip:***@208.70.157.43 <sip%***@208.70.157.43>
;user=phone
To: sip:***@208.70.157.43 <sip%***@208.70.157.43>
;user=phone
From: "Joe Gonzales"
<sip:***@64.124.207.220<sip%***@64.124.207.220>
;user=phone>;tag=3477742912-272141
Contact: <sip:***@64.124.207.220:5060;user=phone;tgrp=100054CUST>

2) Now from here my *redirect server* replied me with below uri in TO &
FROM, but will multiple CONTACT header and on which I have the first CONTACT
user part is with “1” and the others all are same but carry the “1” with
rest of the user part.

IP/2.0 300 Redirect
To: <sip:***@208.70.157.43 <sip%***@208.70.157.43>
;user=phone>;tag=a667a4b9fa6bfa35b
From: "Joe Gonzales"
<sip:***@64.124.207.220<sip%***@64.124.207.220>
;user=phone>;tag=3477742912-272141
Via: SIP/2.0/UDP 64.124.207.220:5060
;branch=z9hG4bKb96ce5413fe01d59101005f4ae3881c6
Contact: <sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=202583VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=202393VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=202562VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=202405VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=202163VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=202203VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=202525VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=201030VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=202330VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=202206VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=202329VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=201906VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=201908VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=201907VEND>,
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=201905VEND>

3)However after sending the ACK my server again sent the another invite to
my vendor with below REQUEST URI with “1” whereas in first CONTACT header
from redirect was not carrying the “1” Contact:
sip:***@64.124.207.220 <sip%***@64.124.207.220>
;dtg=202583VEND.

Request-Line: INVITE
sip:***@64.245.120.88<sip%***@64.245.120.88>SIP/2.0
Request-URI: sip:***@64.245.120.88 <sip%***@64.245.120.88>

Whereby in TO header(of the same INVITE) I do not have the “1” in user part
as below.

To: sip:***@64.245.120.88 <sip%***@64.245.120.88>
Contact: sip:64.124.207.220:5060;tgrp=100054CUST

And because of this my vendor is sending immediate 502 REJECTED.

Status-Line: SIP/2.0 502 Rejected - Called number is not NATNUM

Could anyone please help me on this, whether it is a correct or not,because
as far as I know he user part of the Request uri would be checked first.
User part of the Request uri is valid but the To header is different from
Request uri so now a validation for the User part of the To header will be
performed and if the user part is found to be invalid then a 404 (Not
Found) response should sent back.

Thanks,
Nitin Kapoor

[WORLEY, DALE R (DALE)]

_______________________________________
From: sip-implementors-***@lists.cs.columbia.edu [sip-implementors-***@lists.cs.columbia.edu] On Behalf Of Nitin Kapoor [***@gmail.com]

To: sip:***@64.245.120.88 <sip%***@64.245.120.88>

_______________________________________________

In general, a SIP element should not consider the value of the To header. However, the To header is required to conform to a specific syntax, and this To header does not. The basic structure for this type of To header is "display-name <SIP-URI>". However, if display-name is not quoted, it is restricted to being a "token", and "token" may not contain ":" or "@". The text between <...> is supposed to be a SIP URI, but the ":" is replaced by "%3A", and there is no escaping defined for that position. See section 25.1 of RFC 3261 for the details.

So until you correct the To header (who is generating it?) there is no reason to expect any SIP element to accept the request.

Dale

[Nitin Kapoor]

Dale,

I guess its looks different in sip forum..

Because i have not seen a single packet in original format who is taking
"%3A" in userpart..However i am again sending you the Request line which is
actually quested in uri's.


Request-Line: INVITE
sip:***@64.245.120.88<sip%***@64.245.120.88>SIP/2.0
Request-URI: sip:***@64.245.120.88 <sip%***@64.245.120.88>

Whereby in TO header(of the same INVITE) I do not have the “1” in user part
as below.

To: sip:***@64.245.120.88 <sip%***@64.245.120.88>

Thanks,
Nitin Kapoor

On 18 March 2010 13:52, WORLEY, DALE R (DALE) <***@avaya.com> wrote:

> _______________________________________
> From: sip-implementors-***@lists.cs.columbia.edu [
> sip-implementors-***@lists.cs.columbia.edu] On Behalf Of Nitin Kapoor
> [***@gmail.com]
>
> To: sip:***@64.245.120.88 <sip%***@64.245.120.88> <
> sip%***@64.245.120.88 <sip%***@64.245.120.88>>
>
> _______________________________________________
>
> In general, a SIP element should not consider the value of the To header.
> However, the To header is required to conform to a specific syntax, and
> this To header does not. The basic structure for this type of To header is
> "display-name <SIP-URI>". However, if display-name is not quoted, it is
> restricted to being a "token", and "token" may not contain ":" or "@". The
> text between <...> is supposed to be a SIP URI, but the ":" is replaced by
> "%3A", and there is no escaping defined for that position. See section 25.1
> of RFC 3261 for the details.
>
> So until you correct the To header (who is generating it?) there is no
> reason to expect any SIP element to accept the request.
>
> Dale
>

[WORLEY, DALE R (DALE)]

________________________________________
From: Nitin Kapoor [***@gmail.com]

I guess its looks different in sip forum..

Request-Line: INVITE sip:***@64.245.120.88 SIP/2.0
Request-URI: sip:***@64.245.120.88

Whereby in TO header(of the same INVITE) I do not have the “1” in user part as below.

To: sip:***@64.245.120.88
______________________________________

Ugh, I think my mail system damaged your message. And while the message of yours that I am replying to looks correct, I can see that the quoted lines above are damaged severely. I just now edited them, but they may be damaged further before you see them.

Dale

[Nitin Kapoor]

Anyhow i have resolved the issue by doing a digits manipulation.

Thanks everyone to help me on this.

Regards,
Nitin Kapoor

On 18 March 2010 13:52, WORLEY, DALE R (DALE) <***@avaya.com> wrote:

> _______________________________________
> From: sip-implementors-***@lists.cs.columbia.edu [
> sip-implementors-***@lists.cs.columbia.edu] On Behalf Of Nitin Kapoor
> [***@gmail.com]
>
> To: sip:***@64.245.120.88 <sip%***@64.245.120.88> <
> sip%***@64.245.120.88 <sip%***@64.245.120.88>>
>
> _______________________________________________
>
> In general, a SIP element should not consider the value of the To header.
> However, the To header is required to conform to a specific syntax, and
> this To header does not. The basic structure for this type of To header is
> "display-name <SIP-URI>". However, if display-name is not quoted, it is
> restricted to being a "token", and "token" may not contain ":" or "@". The
> text between <...> is supposed to be a SIP URI, but the ":" is replaced by
> "%3A", and there is no escaping defined for that position. See section 25.1
> of RFC 3261 for the details.
>
> So until you correct the To header (who is generating it?) there is no
> reason to expect any SIP element to accept the request.
>
> Dale
>