[Serusers] Re: [Users] Route, Record Route and quintum

Kanakatti M. Subramanya mahesh at aptela.com
Fri Sep 9 04:52:40 CEST 2005


Brilliantly, and quite eloquently detailed Jan.  Thanx!

FYI, I spent a *looong* time flailing around with Quintium hardware 
trying to get it to do the *correct* thing (and it was for a three 
person account too!)

Finally gave up in disgust, depression and despair.

Mind you, this was just before I discovered that one of our major 
providers was switching to Sonus.
Sonus, I ask you.

Yikes....

Jan Janak wrote:

>OK, I think I know where the confusion comes from, it is like this:
>
>When a user agent sends a SIP request, the request will traverse one ore
>more SIP proxies until it reaches the target user agent. Each proxy and
>user agent along the path of the request will add its Via header field.
>The purpose of Via header fields is to make sure that all replies will
>traverse exactly the same set of proxies (but in reverse order) as the
>request. In other words Via header fields are used to route _replies_.
>They record the path of the request so that replies can follow it.
>
>Route and Record-Route header fields have a slightly different purpose
>-- they are used to route _requests_. Let's assume this scenario:
>
>       INV               INV
>UA A --------> proxy ----------> UA B
>a at 1.2.3.4                        b at 5.6.7.8
>
>User agent A with IP address 1.2.3.4 sends an INVITE request to the
>proxy which forwards the request to user agent B. UA A adds the Contact
>header field in the request. The Contact header field tells UA B that it
>can reach UA A on IP 1.2.3.4. UA B adds a Contact header field to 200 OK
>reply, telling UA A that it can reach B on IP address 5.6.7.8.
>This way both user agents exchange their IP addresses and they do not
>need the proxy anymore. They can easily send all further SIP messages
>directly to each other, because they remember the IP address of the
>remote party from Contact header field. This way all further requests
>would bypass the proxy server.
>
>There are many cases where the proxy server needs to see _all_ future
>SIP messages exchanged between the user agent (for example when
>performing accounting). In this case the proxy server needs tell the
>user agents that they should not exchange future SIP messages directly,
>but they should relay them through the proxy again.
>
>The proxy server can do this by inserting Record-Route header field in
>the INVITE message. The Record-Route header field contains the IP
>address of the proxy and once the INVITE message reaches UA B, it extracts
>the IP address of the proxy server from Record-Route header field and
>store it in memory along with the IP address of the remote party (UA A).
>So UA B knows the IP address of UA A and it also knows that it should
>send all future requests to UA A through the proxy server.
>
>UA A should also send all future SIP requests to UA B through the proxy
>server, but it does not know it yet, because the proxy server added
>Record-Route header field to the INVITE message (which will only reach
>UA B). UA B has to tell UA A that all future SIP requests should be sent
>through the proxy, and it does so by copying all Record-Route header
>fields (in our example there will be only one) from the INVITE message to 
>200 OK (which is sent from UA B to UA A). UA A will then extract
>Record-Route header fields along with Contact from 200 OK and store it
>in memory. At this point both user agents know the IP address of the
>remote party and that they should relay all SIP messages through the
>proxy.
>
>Now what happens when UA A wants to send an ACK to UA B. It will lookup
>the IP address of the remote party (Contact from 200 OK) from memory and put 
>it in the Request-URI of ACK. The reason why ACK does not have the same
>Request-URI as the original INVITE is that the ACK should be sent to the
>user agent instance that generated 200 OK -- the Request-URI from the
>INVITE would fork if user B had several user agents and this is not
>desirable for ACKs. The URI based on Contact header field never forks,
>it is delivered only to the UA instance that generated 200 OK.
>UA A will also find the URI from the Record-Route header field in memory
>(stored along with the contact of the remote party). It will create a
>Route header field, put the URI in it and append it to the ACK.
>
>RFC3261 says that if there is a Route header field in a SIP message,
>then the message should not be sent to the URI in the Request-URI, but
>to the URI in Route header field and thus the ACK would be sent to the
>proxy. The proxy will then remove the Route header field and because
>there is no other Route header field in our message, it will forward the
>request to the Request-URI which will take the message to UA B.
>
>Note the difference between Record-Route and Route header fields.
>Record-Route header fields tell SIP user agent and proxies where
>_future_ SIP requests should be sent. Route header field are constructed
>from Record-Route header fields and they tell user agent and proxies
>where the request that contains the Route header fields should be sent.
>Two header field names are needed to avoid confusion, because a proxy
>server can add Record-Route header field to _any_ SIP request, including
>requests that already contain Route header fields (using the same name
>would mix them).
>
>The relationship between the two user agents (when they remember the IP
>address of the remote party and IPs of proxies) is called dialog. SIP
>requests that are forwarded using the information extracted from
>Contacts and Record-Route header fields are called "SIP requests within
>dialog" (typically ACK and BYE).
>
>When a user agent sends a SIP request within a dialog, it will always
>put the Contact of the remote party in the Request-URI and copy all URIs
>extracted from Record-Route header fields in Route header fields (in
>either forward or reverse order, based on the direction):
>
>ACK sip:b at 5.6.7.8 SIP/2.0
>Route: sip:proxy at proxy.ip;lr
>...
>
>This is how all recent SIP implementations should behave. Always put the
>Contact of the remote party into the Request-URI and list all proxies that
>inserted Record-Route in Route header fields appended to the message.
>Plain and simple.
>
>Unfortunately there are also older SIP implementations (from pre-RFC3261
>era) that need special care, because record-routing worked differently
>then. In this case the Record-Route does not contain the contact of
>the remote party but the topmost Route header field, and the value of
>the remote contact is preserved in the last Route header field in the
>message. This "compatibility mode" is what makes record routing complex
>and hard to understand, but you can ignore it (you can always find
>details in RFC3261).
>
>In conclusion:
>
>1) Via is used to route responses
>2) Route and Record-Route headers are used to route requests
>3) Proxies use Record-Route to signal that they want to stay on the path
>   of future requests.
>4) User agents use Record-Route headers to build Route headers.
>5) Contact of the remote party is always put in the Request-URI of
>   requests in dialogs.
>6) The list of Route header field is created from the list of
>   Record-Route header fields.
>7) The URI in the topmost Route header field overrides the URI in the
>   Request-URI, so the Request-URI will only be used if there are no
>   more Route header fields.
>
>      Jan.
>
>PS: When talking to Quintum guys, you should ask them to implement what
>    I just described:
>    1) Take the Contact header field from 200 OK and put it in the
>       Request-URI of ACK.
>    2) Take all Record-Route header fields from 200 OK, reverse their
>       order, and append them as Route header fields to the ACK.
>    3) Send the ACK to the topmost Route, if any, otherwise send to the
>       Request-URI.
>
>On 08-09-2005 19:23, Iqbal wrote:
>  
>
>>Hi
>>
>>Just in case I missed something, and before I trash quintum, I have put 
>>the entire dialogue below, to make sure I am getting it correct. If 
>>someone can take a quick look, cause loose routes and strict are driving 
>>me crazy
>>The setup is quintum --- ser---gw  (a.b.c.d ----x.x.x.x ----z.z.z.z)
>>
>>quintum IP = a.b.c.d
>>ser ip = x.x.x.x
>>gw = z.z.z.z
>>gw2 = y.y.y.y
>>
>>Now you cannot get to gw2 direct
>>
>>I have read the RFC, and it may as well be written in French. Also the 
>>Via headers which messages follow those.
>>From what i see we have
>>
>>the RURI, The route headers and the via headers, which is followed and when
>>
>>iqbal
>>
>>
>>
>>
>>U 2005/09/06 15:23:06.414932 a.b.c.d:5060 -> x.x.x.x:5060
>>INVITE sip:07866318220 at x.x.x.x SIP/2.0.
>>CSeq: 1 INVITE.
>>Call-ID: call-00CC9E9D-4FBE-D311-0207-A at a.b.c.d.
>>Contact: <sip:046677 at a.b.c.d>.
>>Content-Type: application/sdp.
>>From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
>>Session-GUID: 859321956-876164920-926430820-875782963.
>>To: <sip:123456789 at x.x.x.x>.
>>Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018.
>>Content-Length: 229.
>>User-Agent: Quintum/1.0.0.
>>Quintum: 
>>0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941.
>>Max-Forwards: 70.
>>.
>>v=0.
>>o=Quintum 7 7 IN IP4 a.b.c.d.
>>s=VoipCall.
>>c=IN IP4 a.b.c.d.
>>t=0 0.
>>m=audio 10254 RTP/AVP 18 4 101.
>>c=IN IP4 a.b.c.d.
>>a=rtpmap:18 g729/8000/1.
>>a=rtpmap:4 g723/8000/1.
>>a=rtpmap:101 telephone-event/8000/1.
>>
>>#
>>U 2005/09/06 15:23:06.452476 x.x.x.x:5060 -> a.b.c.d:5060
>>SIP/2.0 100 trying -- your call is important to us.
>>CSeq: 1 INVITE.
>>Call-ID: call-00CC9E9D-4FBE-D311-0207-A at a.b.c.d.
>>From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
>>To: <sip:123456789 at x.x.x.x>.
>>Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018.
>>Content-Length: 0.
>>Warning: 392 x.x.x.x:5060 "Noisy feedback tells:  pid=24439 
>>req_src_ip=a.b.c.d req_src_port=5060 in_uri=sip:123456789 at x.x.x.x 
>>out_uri=sip:447866318220 at 213.166.5.135:5060 via_cnt==1".
>>.
>>
>>#
>>U 2005/09/06 15:23:06.453034 x.x.x.x:5060 -> z.z.z.z:5060
>>INVITE sip:44123456789 at z.z.z.z:5060 SIP/2.0.
>>Record-Route: <sip:x.x.x.x;ftag=c3ac7b24-a;lr=on>.
>>CSeq: 1 INVITE.
>>Call-ID: call-00CC9E9D-4FBE-D311-0207-A at a.b.c.d.
>>Contact: <sip:046677 at a.b.c.d>.
>>Content-Type: application/sdp.
>>From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
>>Session-GUID: 859321956-876164920-926430820-875782963.
>>To: <sip:123456789 at x.x.x.x>.
>>Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0.
>>Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018.
>>Content-Length: 229.
>>User-Agent: Quintum/1.0.0.
>>Quintum: 
>>0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941.
>>Max-Forwards: 16.
>>.
>>v=0.
>>o=Quintum 7 7 IN IP4 a.b.c.d.
>>s=VoipCall.
>>c=IN IP4 a.b.c.d.
>>t=0 0.
>>m=audio 10254 RTP/AVP 18 4 101.
>>c=IN IP4 a.b.c.d.
>>a=rtpmap:18 g729/8000/1.
>>a=rtpmap:4 g723/8000/1.
>>a=rtpmap:101 telephone-event/8000/1.
>>
>>#
>>U 2005/09/06 15:23:06.465531 z.z.z.z:5060 -> x.x.x.x:5060
>>SIP/2.0 100 trying -- your call is important to us.
>>CSeq: 1 INVITE.
>>Call-ID: call-00CC9E9D-4FBE-D311-0207-A at a.b.c.d.
>>From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
>>To: <sip:123456789 at x.x.x.x>.
>>Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0.
>>Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018.
>>Server: Sip EXpress router (0.8.99-dev (i386/linux)).
>>Content-Length: 0.
>>.
>>
>>########
>>U 2005/09/06 15:23:12.785564 z.z.z.z:5060 -> x.x.x.x:5060
>>SIP/2.0 183 Session Progress.
>>Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0,SIP/2.0/UDP 
>>a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018.
>>From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
>>To: <sip:123456789 at x.x.x.x>;tag=1A4297F4-2C9.
>>Date: Tue, 06 Sep 2005 14:07:59 gmt.
>>Call-ID: call-00CC9E9D-4FBE-D311-0207-A at a.b.c.d.
>>Server: Cisco-SIPGateway/IOS-12.x.
>>CSeq: 1 INVITE.
>>Allow-Events: telephone-event.
>>Contact: <sip:0044123456789 at y.y.y.y:5060>.
>>Record-Route: 
>><sip:z.z.z.z;ftag=c3ac7b24-a;lr=on>,<sip:x.x.x.x;ftag=c3ac7b24-a;lr=on>.
>>Content-Disposition: session;handling=required.
>>Content-Type: application/sdp.
>>Content-Length: 206.
>>.
>>v=0.
>>o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y.
>>s=SIP Call.
>>c=IN IP4 y.y.y.y.
>>t=0 0.
>>m=audio 18590 RTP/AVP 18.
>>c=IN IP4 y.y.y.y.
>>a=rtpmap:18 G729/8000.
>>a=fmtp:18 annexb=yes.
>>
>>-------------------
>>This is where the confusion starts, what path should the 183 take, or 
>>how is the path decided, is it the RURI, or from the RR, or does it not 
>>matter for 183
>>
>>
>>#
>>U 2005/09/06 15:23:12.788274 x.x.x.x:5060 -> a.b.c.d:5060
>>SIP/2.0 183 Session Progress.
>>Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018.
>>From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
>>To: <sip:123456789 at x.x.x.x>;tag=1A4297F4-2C9.
>>Date: Tue, 06 Sep 2005 14:07:59 gmt.
>>Call-ID: call-00CC9E9D-4FBE-D311-0207-A at a.b.c.d.
>>Server: Cisco-SIPGateway/IOS-12.x.
>>CSeq: 1 INVITE.
>>Allow-Events: telephone-event.
>>Contact: <sip:0044123456789 at y.y.y.y:5060>.
>>Record-Route: 
>><sip:z.z.z.z;ftag=c3ac7b24-a;lr=on>,<sip:x.x.x.x;ftag=c3ac7b24-a;lr=on>.
>>Content-Disposition: session;handling=required.
>>Content-Type: application/sdp.
>>Content-Length: 206.
>>.
>>v=0.
>>o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y.
>>s=SIP Call.
>>c=IN IP4 y.y.y.y.
>>t=0 0.
>>m=audio 18590 RTP/AVP 18.
>>c=IN IP4 y.y.y.y.
>>a=rtpmap:18 G729/8000.
>>a=fmtp:18 annexb=yes.
>>
>>
>>----------------------
>>and the OK below, should it not have gone to zzzz and then xxxx, as in 
>>RR, and should not the matching RR be stripped off
>>----------------------
>>
>>###############
>>U 2005/09/06 15:23:16.610600 z.z.z.z:5060 -> x.x.x.x:5060
>>SIP/2.0 200 OK.
>>Via: SIP/2.0/UDP x.x.x.x;branch=z9hG4bKb322.930d8117.0,SIP/2.0/UDP 
>>a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018.
>>From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
>>To: <sip:123456789 at x.x.x.x>;tag=1A4297F4-2C9.
>>Date: Tue, 06 Sep 2005 14:07:59 gmt.
>>Call-ID: call-00CC9E9D-4FBE-D311-0207-A at a.b.c.d.
>>Server: Cisco-SIPGateway/IOS-12.x.
>>CSeq: 1 INVITE.
>>Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, 
>>SUBSCRIBE, NOTIFY, INFO.
>>Allow-Events: telephone-event.
>>Contact: <sip:0044123456789 at y.y.y.y:5060>.
>>Record-Route: 
>><sip:z.z.z.z;ftag=c3ac7b24-a;lr=on>,<sip:x.x.x.x;ftag=c3ac7b24-a;lr=on>.
>>Content-Type: application/sdp.
>>Content-Length: 206.
>>.
>>v=0.
>>o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y.
>>s=SIP Call.
>>c=IN IP4 y.y.y.y.
>>t=0 0.
>>m=audio 18590 RTP/AVP 18.
>>c=IN IP4 y.y.y.y.
>>a=rtpmap:18 G729/8000.
>>a=fmtp:18 annexb=yes.
>>
>>#
>>U 2005/09/06 15:23:16.613003 x.x.x.x:5060 -> a.b.c.d:5060
>>SIP/2.0 200 OK.
>>Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018.
>>From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
>>To: <sip:123456789 at x.x.x.x>;tag=1A4297F4-2C9.
>>Date: Tue, 06 Sep 2005 14:07:59 gmt.
>>Call-ID: call-00CC9E9D-4FBE-D311-0207-A at a.b.c.d.
>>Server: Cisco-SIPGateway/IOS-12.x.
>>CSeq: 1 INVITE.
>>Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, 
>>SUBSCRIBE, NOTIFY, INFO.
>>Allow-Events: telephone-event.
>>Contact: <sip:0044123456789 at y.y.y.y:5060>.
>>Record-Route: 
>><sip:z.z.z.z;ftag=c3ac7b24-a;lr=on>,<sip:x.x.x.x;ftag=c3ac7b24-a;lr=on>.
>>Content-Type: application/sdp.
>>Content-Length: 206.
>>.
>>v=0.
>>o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 y.y.y.y.
>>s=SIP Call.
>>c=IN IP4 y.y.y.y.
>>t=0 0.
>>m=audio 18590 RTP/AVP 18.
>>c=IN IP4 y.y.y.y.
>>a=rtpmap:18 G729/8000.
>>a=fmtp:18 annexb=yes.
>>
>>#
>>U 2005/09/06 15:23:16.726095 a.b.c.d:5060 -> x.x.x.x:5060
>>ACK sip:x.x.x.x;ftag=c3ac7b24-a;lr=on SIP/2.0.
>>CSeq: 1 ACK.
>>Call-ID: call-00CC9E9D-4FBE-D311-0207-A at a.b.c.d.
>>Contact: <sip:046677 at a.b.c.d>.
>>From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
>>Route: <sip:0044123456789 at y.y.y.y:5060>.
>>Session-GUID: 859321956-876164920-926430820-875782963.
>>To: <sip:123456789 at x.x.x.x>;tag=1A4297F4-2C9.
>>Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018.
>>User-Agent: Quintum/1.0.0.
>>Quintum: 
>>0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941.
>>Max-Forwards: 70.
>>.
>>
>>#
>>U 2005/09/06 15:23:16.727888 x.x.x.x:5060 -> y.y.y.y:5060
>>ACK sip:0044123456789 at y.y.y.y:5060 SIP/2.0.
>>Record-Route: <sip:x.x.x.x;ftag=c3ac7b24-a;lr=on>.
>>CSeq: 1 ACK.
>>Call-ID: call-00CC9E9D-4FBE-D311-0207-A at a.b.c.d.
>>Contact: <sip:046677 at a.b.c.d>.
>>From: <sip:046677 at a.b.c.d>;tag=c3ac7b24-a.
>>Session-GUID: 859321956-876164920-926430820-875782963.
>>To: <sip:123456789 at x.x.x.x>;tag=1A4297F4-2C9.
>>Via: SIP/2.0/UDP x.x.x.x;branch=0.
>>Via: SIP/2.0/UDP a.b.c.d;branch=z9hG4bK-tenor-c3ac-7b24-0018.
>>User-Agent: Quintum/1.0.0.
>>Quintum: 
>>0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941.
>>Max-Forwards: 16.
>>.
>>
>>
>>
>>
>>Jan Janak wrote:
>>
>>    
>>
>>>Somehow the value from the first record-route got lost in the user
>>>agent. It put the bottom most Route in the request-uri (which is correct
>>>becuase the implemenetation is most likely a strict router), it also
>>>correctly turned the Contact from 200 OK into Route header field in the
>>>ACK, but the Route header field of the proxy (first one in 200 OK) is
>>>missing in the ACK.
>>>
>>>Jan.
>>>
>>>On 08-09-2005 13:12, Iqbal wrote:
>>>
>>>
>>>      
>>>
>>>>Hi Bogdan
>>>>
>>>>Getting a little clearer :-)
>>>>
>>>>The Contact that ius used is that from the 200 OK which is sent before 
>>>>the ACK (as below), if so that explains where the .134 is coming from.
>>>>
>>>>Also you mentioned that the last hop is taken, but I read somewhere that 
>>>>the topmost route is taken, when forming the route.
>>>>If it is a strict router, does the RURI pick up the info from the 
>>>>Contact header OR the RR,
>>>>Also should RURI not read 111.222.333.444 because that what is in the RR 
>>>>in the 200 OK which is sent, which is what the ACK is showing. Whereas 
>>>>in ur example it reads as below
>>>>
>>>>b) if strict router:
>>>>RURI: <sip:212.156.5.135;ftag=c3ac7b24-a;lr=on>
>>>>R: <sip:111.222.333.444;ftag=c3ac7b24-a;lr=on>
>>>>R: <sip:0044123456789 at 212.156.5.134:5060>
>>>>
>>>>Now if the RURI is as it is in the ACK, the rest should be
>>>>
>>>>Route: <sip:0044123456789 at 212.156.5.135:5060>.
>>>>
>>>>I guess at the end of the day whatever it should be, it isn't, anyone 
>>>>know of howto fix it.
>>>>
>>>>Iqbal
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>Bogdan-Andrei Iancu wrote:
>>>>
>>>>  
>>>>
>>>>        
>>>>
>>>>>Hi Iqbal,
>>>>>
>>>>>the Route Set is formed by the all received RR uris and the Contact uri.
>>>>>When doing LR, the last hop from the Route Set in loaded into RURI and 
>>>>>all RRs are loaded as Route. The request is not routed by RURI, but by 
>>>>>the first Route hdr.
>>>>>
>>>>>So, if the GW does LR and it generates
>>>>>RURI: <sip:0044123456789 at 212.156.5.134:5060>
>>>>> R: <sip:212.156.5.135;ftag=c3ac7b24-a;lr=on>
>>>>> R: <sip:111.222.333.444;ftag=c3ac7b24-a;lr=on>
>>>>>,the request will be sent to the first Route  (212.156.5.135), which 
>>>>>will sent to 111.222.333.444, which will finally use RURI 
>>>>>(212.156.5.134) as no other Route is left in request.
>>>>>
>>>>>regards,
>>>>>bogdan
>>>>>
>>>>>Iqbal wrote:
>>>>>
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>>>>Hi
>>>>>>
>>>>>>This makes a little sense :-), according to a), is the path now taken
>>>>>>.444 --> .135, if so what does the RURI show.
>>>>>>
>>>>>>If the path is that shown by Route headers, then I cannot send it to
>>>>>>.134, since that gateway does not respond directly, and will reject the
>>>>>>ACK.
>>>>>>
>>>>>>Where does the RR, Route headers pick up the info from, I thought that
>>>>>>the Route gets it from what is in the RR
>>>>>>
>>>>>>Iqbal
>>>>>>
>>>>>>On 9/7/2005, "Bogdan-Andrei Iancu" <bogdan at voice-system.ro> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>      
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Hi Iqbal,
>>>>>>>
>>>>>>>considering 200 OK the Route Set:
>>>>>>>RR: <sip:212.156.5.135;ftag=c3ac7b24-a;lr=on>
>>>>>>>RR: <sip:111.222.333.444;ftag=c3ac7b24-a;lr=on>
>>>>>>>CT: <sip:0044123456789 at 212.156.5.134:5060>
>>>>>>>
>>>>>>>the ACK should be:
>>>>>>>a)if loose router:
>>>>>>>RURI: <sip:0044123456789 at 212.156.5.134:5060>
>>>>>>>R: <sip:212.156.5.135;ftag=c3ac7b24-a;lr=on>
>>>>>>>R: <sip:111.222.333.444;ftag=c3ac7b24-a;lr=on>
>>>>>>>b) if strict router:
>>>>>>>RURI: <sip:212.156.5.135;ftag=c3ac7b24-a;lr=on>
>>>>>>>R: <sip:111.222.333.444;ftag=c3ac7b24-a;lr=on>
>>>>>>>R: <sip:0044123456789 at 212.156.5.134:5060>
>>>>>>>
>>>>>>>the ACK you posted looks like an unsuccessful attempt of a strict 
>>>>>>>routing.
>>>>>>>
>>>>>>>regards,
>>>>>>>bogdan
>>>>>>>
>>>>>>>Iqbal wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>        
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>Hi
>>>>>>>>
>>>>>>>>I have a strange looking dialogue, after sending a 200 OK to a quintum
>>>>>>>>box, and get back an ACK, but the Route field seems to be wrong, can
>>>>>>>>someone confirm this.
>>>>>>>>
>>>>>>>>--------
>>>>>>>>U 2005/09/06 15:23:16.613003 111.222.333.444:5060 -> 10.20.30.40:5060
>>>>>>>>SIP/2.0 200 OK.
>>>>>>>>Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018.
>>>>>>>>From: <sip:046677 at 10.20.30.40>;tag=c3ac7b24-a.
>>>>>>>>To: <sip:123456789 at 111.222.333.444>;tag=1A4297F4-2C9.
>>>>>>>>Date: Tue, 06 Sep 2005 14:07:59 gmt.
>>>>>>>>Call-ID: call-00CC9E9D-4FBE-D311-0207-A at 10.20.30.40.
>>>>>>>>Server: Cisco-SIPGateway/IOS-12.x.
>>>>>>>>CSeq: 1 INVITE.
>>>>>>>>Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER,
>>>>>>>>SUBSCRIBE, NOTIFY, INFO.
>>>>>>>>Allow-Events: telephone-event.
>>>>>>>>Contact: <sip:0044123456789 at 212.156.5.134:5060>.
>>>>>>>>Record-Route:
>>>>>>>><sip:212.156.5.135;ftag=c3ac7b24-a;lr=on>,<sip:111.222.333.444;ftag=c3ac7b24-a;lr=on>. 
>>>>>>>>
>>>>>>>>
>>>>>>>>Content-Type: application/sdp.
>>>>>>>>Content-Length: 206.
>>>>>>>>.
>>>>>>>>v=0.
>>>>>>>>o=CiscoSystemsSIP-GW-UserAgent 7438 1091 IN IP4 212.156.5.134.
>>>>>>>>s=SIP Call.
>>>>>>>>c=IN IP4 212.156.5.134.
>>>>>>>>t=0 0.
>>>>>>>>m=audio 18590 RTP/AVP 18.
>>>>>>>>c=IN IP4 212.156.5.134.
>>>>>>>>a=rtpmap:18 G729/8000.
>>>>>>>>a=fmtp:18 annexb=yes.
>>>>>>>>
>>>>>>>>#
>>>>>>>>U 2005/09/06 15:23:16.726095 10.20.30.40:5060 -> 111.222.333.444:5060
>>>>>>>>ACK sip:111.222.333.444;ftag=c3ac7b24-a;lr=on SIP/2.0.
>>>>>>>>CSeq: 1 ACK.
>>>>>>>>Call-ID: call-00CC9E9D-4FBE-D311-0207-A at 10.20.30.40.
>>>>>>>>Contact: <sip:046677 at 10.20.30.40>.
>>>>>>>>From: <sip:046677 at 10.20.30.40>;tag=c3ac7b24-a.
>>>>>>>>Route: <sip:0044123456789 at 212.156.5.134:5060>.
>>>>>>>>Session-GUID: 859321956-876164920-926430820-875782963.
>>>>>>>>To: <sip:123456789 at 111.222.333.444>;tag=1A4297F4-2C9.
>>>>>>>>Via: SIP/2.0/UDP 10.20.30.40;branch=z9hG4bK-tenor-c3ac-7b24-0018.
>>>>>>>>User-Agent: Quintum/1.0.0.
>>>>>>>>Quintum:
>>>>>>>>0c01030b0232360501000715000000000000000d006c0a828180803034363637371301000f0b413031322d313033353941. 
>>>>>>>>
>>>>>>>>
>>>>>>>>Max-Forwards: 70.
>>>>>>>>----------------
>>>>>>>>
>>>>>>>>I thought the Route field should have the data which it pulls from the
>>>>>>>>Record Route headers
>>>>>>>>
>>>>>>>>tks
>>>>>>>>
>>>>>>>>iqbal
>>>>>>>>
>>>>>>>>_______________________________________________
>>>>>>>>Users mailing list
>>>>>>>>Users at openser.org
>>>>>>>>http://openser.org/cgi-bin/mailman/listinfo/users
>>>>>>>>
>>>>>>>> 
>>>>>>>>          
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>        
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>      
>>>>>>
>>>>>>            
>>>>>>
>>>>>.
>>>>>
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>>_______________________________________________
>>>>Serusers mailing list
>>>>serusers at lists.iptel.org
>>>>http://lists.iptel.org/mailman/listinfo/serusers
>>>>  
>>>>
>>>>        
>>>>
>>>.
>>>
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>Serusers mailing list
>>serusers at lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serusers
>>    
>>
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050908/67b808b0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mahesh.vcf
Type: text/x-vcard
Size: 255 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050908/67b808b0/attachment.vcf>


More information about the sr-users mailing list