*sigh*
Everything in a SIP message can be broken down into component
parts in the grammar.
A record-route is composed of the word "Record-Route" followed a colon
followed by comma-separated rec-routes. This is shown in RFC3261 as:
Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route)
The rec-route decomposes into a name-addr followed by any number of
rr-parameters separated by semi-colons. This is shown by:
rec-route = name-addr *( SEMI rr-param )
rr-param = generic-param
In your example, there is only one rec-route which is:
<sip:79.99.193.141;lr;ftag=4F6C3030343338350007D3E5;vsf=AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA--;vst=AAAAAHQEBAMFAAUABwZzAg0deQ4XHwAKAAAKCy4xNDE
-;did=9b.dcc08423>
The name-addr is an optional display-name followed by an addr-spec in
between < and >:
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
In your example the addr-spec is:
sip:79.99.193.141;lr;ftag=4F6C3030343338350007D3E5;vsf=AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAA--;vst=AAAAAHQEBAMFAAUABwZzAg0deQ4XHwAKAAAKCy4xNDE-
;did=9b.dcc08423
The addr-spec is a URI of some kind:
addr-spec = SIP-URI / SIPS-URI / absoluteURI
You have a SIP-URI which is defined as:
SIP-URI = "sip:" [ userinfo ] hostport
uri-parameters [ headers ]
If you follow the grammar, you can see the uri-parameters.
The uri-parameters in your example are:
;lr;ftag=4F6C3030343338350007D3E5;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAA--;vst=AAAAAHQEBAMFAAUABwZzAg0deQ4XHwAKAAAKCy4xNDE-;did=9b.dcc08423
each uri-parameter is preceded by a semi-colon:
uri-parameters = *( ";" uri-parameter)
So individually the uri-parameter list is:
lr
ftag=4F6C3030343338350007D3E5
vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA--
vst=AAAAAHQEBAMFAAUABwZzAg0deQ4XHwAKAAAKCy4xNDE-
did=9b.dcc08423
And the ftag is a valid example of a uri-parameter (an other-param):
other-param = pname [ "=" pvalue ]
ftag=4F6C3030343338350007D3E5
I hope this helps.
Regards
Attila
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Nitin Kapoor
Sent: 22 March 2011 14:46
To: [email protected]
Subject: Re: [Sip-implementors] Ftag Parameter in Record-Route
Dear All,
Could you please help me on this to understand this.
Thanks,
Nitin
On Tue, Mar 22, 2011 at 9:46 AM, Attila Sipos
<[email protected]>wrote:
> Hi,
>
> I'm saying that the ftag parameter is a legal parameter.
> I have no idea what the ftag parameter means but I'm saying that the
> grammar of it is legal as defined by RFC3261.
>
> One of the Record-Route components is the URI and the ftag is a valid
> grammar as defined by the uri-parameter grammar and other-param
> grammar.
>
> uri-parameter = transport-param / user-param / method-param
> / ttl-param / maddr-param / lr-param /
other-param
> other-param = pname [ "=" pvalue ]
>
> the value of ftag you showed contains no special characters and is a
> valid pvalue
>
> *ftag=4F6C3030343338350007D3E5;*
>
>
> Regards
>
> Attila
>
>
>
>
> ------------------------------
> *From:* Nitin Kapoor [mailto:[email protected]]
> *Sent:* 22 March 2011 13:36
> *To:* Attila Sipos
> *Cc:* [email protected]
>
> *Subject:* Re: [Sip-implementors] Ftag Parameter in Record-Route
>
> Dear Attila,
>
> So you are saying that whatever is coming in FTAG are correct as
below?
>
> *
> <sip:79.99.193.141;lr;ftag=4F6C3030343338350007D3E5;vsf=AAAAAAAAAAAAAA
> AAAAAAAAAAAAAAAAAAAAAAAA--;vst=AAAAAHQEBAMFAAUABwZzAg0deQ4XHwAKAAAKCy4
> xNDE-;did=9b.dcc08423>
> *
>
> Thanks,
> Nitin
>
> On Tue, Mar 22, 2011 at 2:56 AM, Attila Sipos
> <[email protected]>
> wrote:
>
>>
>> Record-Route headers often have opaque parameters which are not in
>> any draft or RFC. Such parameters have no meaning except to the
>> entity which added them.
>>
>> For Record-Route all you have to do is reflect the route back.
>> When you use the learnt route in a Route header you have to quote the
>> full learnt route including all its parameters.
>> As long as the parameters follow the general grammar rules, it should
>> not matter what is the content.
>>
>> So in the case of the ftag, it looks legal and should be used as is
>> supplied (along with the rest of the route information).
>> So, your SBC should not be rejecting it due to the ftag header.
>> If it does, the SBC is behaving wrongly.
>>
>> (When I get a problem like this I often strip out the suspect header
>> and try to send the message using something like SIPP to see if the
>> message is still rejected)
>>
>> Regards
>>
>> Attila
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: [email protected] on behalf of
>> Nitin Kapoor
>> Sent: Tue 22/03/2011 00:20
>> To: [email protected]
>> Subject: Re: [Sip-implementors] Ftag Parameter in Record-Route
>>
>> Dear All,
>>
>> Could anyone please help me out on this.
>>
>> Thanks,
>> Nitin
>>
>> On Mon, Mar 21, 2011 at 5:53 PM, Nitin Kapoor <[email protected]
>> >wrote:
>>
>> > Dear All,
>> >
>> > i am facing the problem with one of my customer where i noticed
>> > that Record-Route header containing the "ftag" parameter.
>> >
>> > INVITE sip:[email protected] SIP/2.0
>> > Record-Route:
>> >
>> <sip:79.99.193.141;lr;ftag=4F6C3030343338350007D3E5;vsf=AAAAAAAAAAAAA
>> AAAAAAAAAAAAAAAAAAAAAAAAA--;vst=AAAAAHQEBAMFAAUABwZzAg0deQ4XHwAKAAAKC
>> y4xNDE-;did=9b.dcc08423>
>> > Content-Type:application/sdp
>> > To:sip:[email protected]
>> > From:sip:[email protected]
>> > ;cpc=ordinary;tag=4F6C3030343338350007D3E5
>> > Privacy:none
>> > P-Asserted-Identity:sip:[email protected];cpc=ordinary
>> > Supported:100rel,timer
>> > Expires:120
>> > Date:Thu, 10 Mar 2011 20:02:01 GMT
>> > Session-Expires:3600
>> > Min-SE:90
>> > Call-ID:01FF945D4C81400000054AC4@TB004385_VOIP0
>> > CSeq:1 INVITE
>> > Route:<sip:79.99.193.141:5060;lr;transport=udp>
>> > Max-Forwards:69
>> > Timestamp:512997
>> > User-Agent:TB004385
>> > Contact:sip:[email protected]:5061
>> > Via: SIP/2.0/UDP 79.99.193.141;branch=z9hG4bK1f07.16311b13.0
>> > Via:SIP/2.0/UDP 79.99.193.138:5060
>> >
>> ;received=79.99.193.138;branch=z9hG4bKDD5A2E7439308FCEA1D45366471A437
>> C;rport=5060
>> > Content-Length:344
>> >
>> > Now above is my INVITE which is coming from UAC to SBC and my SBC
>> > is sending 400 Bad Request to UAC. My doubt is that FTAG is
>> > containing the invalid correct hence SBC is unable to understand
>> > the nature of this
>> invite
>> > hence sending the 400.
>> >
>> > Could anyone please help me out to understand this? also is there
>> > any
>> limit
>> > for the character in FTAG?
>> >
>> > Thanks,
>> > Nitin Kapoor
>> >
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>>
>>
>> .
>>
>
>
>
> .
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
