i based my reasoning regarding the need to add record route only to the initial request to this text in rfc3261. i guess the proxy may add record route to any request, but since it doesn't have any effect to the dialog state, i don't see a point of doing it.
-- juha
12.2 Requests within a Dialog
Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog s route set to be modified, although they may modify the remote target URI. Specifi- cally, requests that are not target refresh requests do not modify the dialog s remote target URI, and requests that are target refresh requests do. For dialogs that have been established with an INVITE, the only target refresh request defined is re-INVITE (see Section 14). Other extensions may define different target refresh requests for dialogs established in other ways. Note that an ACK is NOT a target refresh request. Target refresh requests only update the dialog s remote target URI, and not the route set formed from the Record-Route. Updating the latter would introduce severe backwards compatibility problems with RFC 2543-compliant systems.
Yes, you are right, I confused two things -- target refreshers are not related to record-routing, they update just remote target, thanks for pointing this out.
Anyway, you still don't know if message FOOBAR creates dialog.
Jan.
On 03-01 19:14, Juha Heinanen wrote:
i based my reasoning regarding the need to add record route only to the initial request to this text in rfc3261. i guess the proxy may add record route to any request, but since it doesn't have any effect to the dialog state, i don't see a point of doing it.
-- juha
12.2 Requests within a Dialog
Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog s route set to be modified, although they may modify the remote target URI. Specifi- cally, requests that are not target refresh requests do not modify the dialog s remote target URI, and requests that are target refresh requests do. For dialogs that have been established with an INVITE, the only target refresh request defined is re-INVITE (see Section 14). Other extensions may define different target refresh requests for dialogs established in other ways. Note that an ACK is NOT a target refresh request. Target refresh requests only update the dialog s remote target URI, and not the route set formed from the Record-Route. Updating the latter would introduce severe backwards compatibility problems with RFC 2543-compliant systems.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Jan Janak wrote:
Yes, you are right, I confused two things -- target refreshers are not related to record-routing, they update just remote target, thanks for pointing this out.
Anyway, you still don't know if message FOOBAR creates dialog.
Well, IMO absence or presence of tag in the To header field should be the definite difference between the two. INVITE which creates a dialg would be To-tag-less, while one that refreshes a dialog would usually have one. And if my memory serves according to the RFC INVITE is the only type of message which can create a dialog.
-Maxim
Jan.
On 03-01 19:14, Juha Heinanen wrote:
i based my reasoning regarding the need to add record route only to the initial request to this text in rfc3261. i guess the proxy may add record route to any request, but since it doesn't have any effect to the dialog state, i don't see a point of doing it.
-- juha
12.2 Requests within a Dialog
Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog s route set to be modified, although they may modify the remote target URI. Specifi- cally, requests that are not target refresh requests do not modify the dialog s remote target URI, and requests that are target refresh requests do. For dialogs that have been established with an INVITE, the only target refresh request defined is re-INVITE (see Section 14). Other extensions may define different target refresh requests for dialogs established in other ways. Note that an ACK is NOT a target refresh request. Target refresh requests only update the dialog s remote target URI, and not the route set formed from the Record-Route. Updating the latter would introduce severe backwards compatibility problems with RFC 2543-compliant systems.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Maxim Sobolev writes:
Well, IMO absence or presence of tag in the To header field should be the definite difference between the two. INVITE which creates a dialg would be To-tag-less, while one that refreshes a dialog would usually have one. And if my memory serves according to the RFC INVITE is the only type of message which can create a dialog.
also subscribe and even notify can create a dialog.
-- juha
I love this mailing list :-)
So, in my case where I am routing phone calls and not doing any SUBSCRIBE/NOTIFY stuff, my original assertion seems to be correct.
I need to handle 3 requests
1) a loose_route() 2) a REGISTER 3) an INVITE
The INVITE stamps all dialogs with a record route, all subsequent BYE/ACK/CANCEL stuff rides on the loose_routing. Anything that doesn't match one of the 3 cases above is an error.
Right?
---greg
Juha Heinanen wrote:
Maxim Sobolev writes:
Well, IMO absence or presence of tag in the To header field should be the definite difference between the two. INVITE which creates a dialg would be To-tag-less, while one that refreshes a dialog would usually have one. And if my memory serves according to the RFC INVITE is the only type of message which can create a dialog.
also subscribe and even notify can create a dialog.
-- juha
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On 03-01 11:58, Greg Fausak wrote:
I love this mailing list :-)
So, in my case where I am routing phone calls and not doing any SUBSCRIBE/NOTIFY stuff, my original assertion seems to be correct.
I need to handle 3 requests
- a loose_route()
- a REGISTER
- an INVITE
The INVITE stamps all dialogs with a record route, all subsequent BYE/ACK/CANCEL stuff rides on the loose_routing. Anything that doesn't match one of the 3 cases above is an error.
Only BYE/ACK. CANCELs are not record routed (since no 200 OK was received by the sender). But because CANCEL contains the same Request-URI as the associated INVITE, it is OK.
But yes, you can record-route INVITEs only, that's probably what you are interested in.
Jan.
I have a hard time articulating my real question :-)
What I was asking was :
As long as I record route an INVITE, does that make everything else record-routed (meaning that I pick it up with the loose_route())?
The answer is no, you still have to route calls...loose_route() doesn't pick up everything.
Anyway, here is a packet trace from a call.
1) Inbound, through a PSTN. 2) Routed to the UA. 3) The caller hangs up, causing a cancel.
Does the trace look right? In particular, the CANCELing 200 message and the cancelled 487...is that the way it is supposed to look?
---greg
Jan Janak wrote:
On 03-01 11:58, Greg Fausak wrote:
I love this mailing list :-)
So, in my case where I am routing phone calls and not doing any SUBSCRIBE/NOTIFY stuff, my original assertion seems to be correct.
I need to handle 3 requests
- a loose_route()
- a REGISTER
- an INVITE
The INVITE stamps all dialogs with a record route, all subsequent BYE/ACK/CANCEL stuff rides on the loose_routing. Anything that doesn't match one of the 3 cases above is an error.
Only BYE/ACK. CANCELs are not record routed (since no 200 OK was received by the sender). But because CANCEL contains the same Request-URI as the associated INVITE, it is OK.
But yes, you can record-route INVITEs only, that's probably what you are interested in.
Jan.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
CurrentTrace
File: /tmp/eth1.w Generated: Sun Jan 11 14:08:30 2004 Traced on: Sun Jan 11 14:04:28 2004 Created by:sip_scenario.pl version=1.1.2
PSTN Incoming named.com PHONE 216.87.144.196 198.212.169.252 198.212.169.13 66.228.44.212 | | | | <Call><PFrame><DeltaTime><Date><Time> | | | | |>F1 INVITE (sdp)------>| | | 1 PF:1 0.0000 11/Jan/04 14:04:28.3275 | | | | | trying -- your call is important to us 100 F2 | | |<mportant to us 100 F2<| | | 1 PF:2 0.0092 11/Jan/04 14:04:28.3367 | | | | | |>F3 INVITE (sdp)------>| | 1 PF:3 0.0171 11/Jan/04 14:04:28.3538 | | | | | trying -- your call is important to us 100 F4 | | | |<mportant to us 100 F4<| | 1 PF:4 0.2520 11/Jan/04 14:04:28.6059 | | | | | | |>F5 INVITE (sdp)------>| 1 PF:5 0.0000 11/Jan/04 14:04:28.6059 | | | | | | |<------- Trying 100 F6<| 1 PF:6 0.2259 11/Jan/04 14:04:28.8317 | | | | | | |<------ Ringing 180 F7<| 1 PF:7 0.1065 11/Jan/04 14:04:28.9383 | | | | | |<------ Ringing 180 F8<| | 1 PF:8 0.0002 11/Jan/04 14:04:28.9385 | | | | |<------ Ringing 180 F9<| | | 1 PF:9 0.0003 11/Jan/04 14:04:28.9387 | | | | | | | | | | | | | | | | | | | | | | | | |>F10 CANCEL ---------->| | | 1 PF:12 9.9758 11/Jan/04 14:04:38.9146 | | | | | |>F11 CANCEL ---------->| | 1 PF:13 0.0086 11/Jan/04 14:04:38.9232 | | | | |<-- cancelling 200 F12<| | | 1 PF:14 0.0001 11/Jan/04 14:04:38.9233 | | | | | Request cancelled 487 F13 | | |<est cancelled 487 F13<| | | 1 PF:15 0.0000 11/Jan/04 14:04:38.9233 | | | | |>F14 ACK ------------->| | | 1 PF:16 0.0139 11/Jan/04 14:04:38.9372 | | | | | | |>F15 CANCEL ---------->| 1 PF:17 0.1558 11/Jan/04 14:04:39.0930 | | | | | |<-- cancelling 200 F16<| | 1 PF:18 0.0011 11/Jan/04 14:04:39.0941 | | | | | Request cancelled 487 F17 | | | |<est cancelled 487 F17<| | 1 PF:19 0.0000 11/Jan/04 14:04:39.0941 | | | | | |>F18 ACK ------------->| | 1 PF:20 0.0000 11/Jan/04 14:04:39.0941 | | | | | | |<---------- OK 200 F19<| 1 PF:21 0.0491 11/Jan/04 14:04:39.1432 | | | | | | Request Cancelled 487 F20 | | | |<est Cancelled 487 F20<| 1 PF:22 0.0433 11/Jan/04 14:04:39.1865 | | | | | | |>F21 ACK ------------->| 1 PF:23 0.0002 11/Jan/04 14:04:39.1867
================================================================================
SIP MESSAGE 1 216.87.144.196:54864(PSTN) -> 198.212.169.252:5060(Incoming) UDP Frame 1 11/Jan/04 14:04:28.3275 TimeFromPreviousSipFrame=0.0000 TimeFromStart=0.0000 INVITE sip:9723937976@198.212.169.252:5060 SIP/2.0 Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252 Date: Sun, 11 Jan 2004 20:04:36 GMT Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 Supported: timer,100rel Min-SE: 1800 Cisco-Guid: 924534062-1135088088-2663245746-559418058 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO CSeq: 101 INVITE Max-Forwards: 15 Remote-Party-ID: sip:9723935295@216.87.144.196;party=calling;screen=yes;privacy=off Timestamp: 1073851476 Contact: sip:9723935295@216.87.144.196:5060 Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Length: 356
v=0 o=CiscoSystemsSIP-GW-UserAgent 9162 9954 IN IP4 216.87.144.196 s=SIP Call c=IN IP4 216.87.144.196 t=0 0 m=audio 16838 RTP/AVP 0 18 4 101 19 c=IN IP4 216.87.144.196 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:4 G723/8000 a=fmtp:4 annexa=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:19 CN/8000
================================================================================
SIP MESSAGE 2 198.212.169.252:5060(Incoming) -> 216.87.144.196:5060(PSTN) UDP Frame 2 11/Jan/04 14:04:28.3367 TimeFromPreviousSipFrame=0.0092 TimeFromStart=0.0092 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 CSeq: 101 INVITE Server: Sip EXpress router (0.8.12 (i386/linux)) Content-Length: 0 Warning: 392 198.212.169.252:5060 "Noisy feedback tells: pid=1974 req_src_ip=216.87.144.196 req_src_port=54864 in_uri=sip:9723937976@198.212.169.252:5060 out_uri=sip:9723937976@named.com via_cnt==1"
================================================================================
SIP MESSAGE 3 198.212.169.252:5060(Incoming) -> 198.212.169.13:5060(named.com) UDP Frame 3 11/Jan/04 14:04:28.3538 TimeFromPreviousSipFrame=0.0171 TimeFromStart=0.0263 INVITE sip:9723937976@named.com SIP/2.0 Via: SIP/2.0/UDP 198.212.169.252;branch=z9hG4bKa1d.eaf3b226.0 Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252 Date: Sun, 11 Jan 2004 20:04:36 GMT Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 Supported: timer,100rel Min-SE: 1800 Cisco-Guid: 924534062-1135088088-2663245746-559418058 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO CSeq: 101 INVITE Max-Forwards: 14 Remote-Party-ID: sip:9723935295@216.87.144.196;party=calling;screen=yes;privacy=off Timestamp: 1073851476 Contact: sip:9723935295@216.87.144.196:5060 Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Length: 356
v=0 o=CiscoSystemsSIP-GW-UserAgent 9162 9954 IN IP4 216.87.144.196 s=SIP Call c=IN IP4 216.87.144.196 t=0 0 m=audio 16838 RTP/AVP 0 18 4 101 19 c=IN IP4 216.87.144.196 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:4 G723/8000 a=fmtp:4 annexa=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:19 CN/8000
================================================================================
SIP MESSAGE 4 198.212.169.13:5060(named.com) -> 198.212.169.252:5060(Incoming) UDP Frame 4 11/Jan/04 14:04:28.6059 TimeFromPreviousSipFrame=0.2520 TimeFromStart=0.2783 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 198.212.169.252;branch=z9hG4bKa1d.eaf3b226.0 Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 CSeq: 101 INVITE Server: Sip EXpress router (0.8.12 (i386/linux)) Content-Length: 0 Warning: 392 198.212.169.13:5060 "Noisy feedback tells: pid=6175 req_src_ip=198.212.169.252 req_src_port=5060 in_uri=sip:9723937976@named.com out_uri=sip:9723937976@66.228.44.212:5060 via_cnt==2"
================================================================================
SIP MESSAGE 5 198.212.169.13:5060(named.com) -> 66.228.44.212:5060(PHONE) UDP Frame 5 11/Jan/04 14:04:28.6059 TimeFromPreviousSipFrame=0.0000 TimeFromStart=0.2783 INVITE sip:9723937976@66.228.44.212:5060 SIP/2.0 Record-Route: sip:9723937976@198.212.169.13;ftag=37BD7C50-1493;lr Via: SIP/2.0/UDP 198.212.169.13;branch=z9hG4bKa1d.269f0b37.0 Via: SIP/2.0/UDP 198.212.169.252;branch=z9hG4bKa1d.eaf3b226.0 Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252 Date: Sun, 11 Jan 2004 20:04:36 GMT Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 Supported: timer,100rel Min-SE: 1800 Cisco-Guid: 924534062-1135088088-2663245746-559418058 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO CSeq: 101 INVITE Max-Forwards: 13 Remote-Party-ID: sip:9723935295@216.87.144.196;party=calling;screen=yes;privacy=off Timestamp: 1073851476 Contact: sip:9723935295@216.87.144.196:5060 Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Length: 356
v=0 o=CiscoSystemsSIP-GW-UserAgent 9162 9954 IN IP4 216.87.144.196 s=SIP Call c=IN IP4 216.87.144.196 t=0 0 m=audio 16838 RTP/AVP 0 18 4 101 19 c=IN IP4 216.87.144.196 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:4 G723/8000 a=fmtp:4 annexa=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:19 CN/8000
================================================================================
SIP MESSAGE 6 66.228.44.212:50238(PHONE) -> 198.212.169.13:5060(named.com) UDP Frame 6 11/Jan/04 14:04:28.8317 TimeFromPreviousSipFrame=0.2259 TimeFromStart=0.5042 SIP/2.0 100 Trying Via: SIP/2.0/UDP 198.212.169.13;branch=z9hG4bKa1d.269f0b37.0,SIP/2.0/UDP 198.212.169.252;branch=z9hG4bKa1d.eaf3b226.0,SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 Date: Sun, 11 Jan 2004 20:03:54 GMT CSeq: 101 INVITE Server: CSCO/5 Contact: sip:9723937976@66.228.44.212:5060 Record-Route: sip:9723937976@198.212.169.13;ftag=37BD7C50-1493;lr Content-Length: 0
================================================================================
SIP MESSAGE 7 66.228.44.212:50238(PHONE) -> 198.212.169.13:5060(named.com) UDP Frame 7 11/Jan/04 14:04:28.9383 TimeFromPreviousSipFrame=0.1065 TimeFromStart=0.6107 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 198.212.169.13;branch=z9hG4bKa1d.269f0b37.0,SIP/2.0/UDP 198.212.169.252;branch=z9hG4bKa1d.eaf3b226.0,SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252;tag=0007ebcdcd32003c6e0e395f-1ba5a1f2 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 Date: Sun, 11 Jan 2004 20:03:54 GMT CSeq: 101 INVITE Server: CSCO/5 Contact: sip:9723937976@66.228.44.212:5060 Record-Route: sip:9723937976@198.212.169.13;ftag=37BD7C50-1493;lr Content-Length: 0
================================================================================
SIP MESSAGE 8 198.212.169.13:5060(named.com) -> 198.212.169.252:5060(Incoming) UDP Frame 8 11/Jan/04 14:04:28.9385 TimeFromPreviousSipFrame=0.0002 TimeFromStart=0.6109 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 198.212.169.252;branch=z9hG4bKa1d.eaf3b226.0,SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252;tag=0007ebcdcd32003c6e0e395f-1ba5a1f2 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 Date: Sun, 11 Jan 2004 20:03:54 GMT CSeq: 101 INVITE Server: CSCO/5 Contact: sip:9723937976@66.228.44.212:5060 Record-Route: sip:9723937976@198.212.169.13;ftag=37BD7C50-1493;lr Content-Length: 0
================================================================================
SIP MESSAGE 9 198.212.169.252:5060(Incoming) -> 216.87.144.196:5060(PSTN) UDP Frame 9 11/Jan/04 14:04:28.9387 TimeFromPreviousSipFrame=0.0003 TimeFromStart=0.6112 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252;tag=0007ebcdcd32003c6e0e395f-1ba5a1f2 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 Date: Sun, 11 Jan 2004 20:03:54 GMT CSeq: 101 INVITE Server: CSCO/5 Contact: sip:9723937976@66.228.44.212:5060 Record-Route: sip:9723937976@198.212.169.13;ftag=37BD7C50-1493;lr Content-Length: 0
================================================================================
SIP MESSAGE 10 216.87.144.196:54864(PSTN) -> 198.212.169.252:5060(Incoming) UDP Frame 12 11/Jan/04 14:04:38.9146 TimeFromPreviousSipFrame=9.9758 TimeFromStart=10.5870 CANCEL sip:9723937976@198.212.169.252:5060 SIP/2.0 Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252 Date: Sun, 11 Jan 2004 20:04:36 GMT Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 CSeq: 101 CANCEL Max-Forwards: 15 Timestamp: 1073851487 Content-Length: 0
================================================================================
SIP MESSAGE 11 198.212.169.252:5060(Incoming) -> 198.212.169.13:5060(named.com) UDP Frame 13 11/Jan/04 14:04:38.9232 TimeFromPreviousSipFrame=0.0086 TimeFromStart=10.5957 CANCEL sip:9723937976@named.com SIP/2.0 Via: SIP/2.0/UDP 198.212.169.252;branch=z9hG4bKa1d.eaf3b226.0 Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252 Date: Sun, 11 Jan 2004 20:04:36 GMT Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 CSeq: 101 CANCEL Max-Forwards: 14 Timestamp: 1073851487 Content-Length: 0
================================================================================
SIP MESSAGE 12 198.212.169.252:5060(Incoming) -> 216.87.144.196:5060(PSTN) UDP Frame 14 11/Jan/04 14:04:38.9233 TimeFromPreviousSipFrame=0.0001 TimeFromStart=10.5958 SIP/2.0 200 cancelling Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252;tag=b3c79317285d521811732e4a421c35ef-40c7 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 CSeq: 101 CANCEL Server: Sip EXpress router (0.8.12 (i386/linux)) Content-Length: 0 Warning: 392 198.212.169.252:5060 "Noisy feedback tells: pid=1975 req_src_ip=216.87.144.196 req_src_port=54864 in_uri=sip:9723937976@198.212.169.252:5060 out_uri=sip:9723937976@named.com via_cnt==1"
================================================================================
SIP MESSAGE 13 198.212.169.252:5060(Incoming) -> 216.87.144.196:5060(PSTN) UDP Frame 15 11/Jan/04 14:04:38.9233 TimeFromPreviousSipFrame=0.0000 TimeFromStart=10.5958 SIP/2.0 487 Request cancelled Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252;tag=b3c79317285d521811732e4a421c35ef-40c7 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 CSeq: 101 INVITE Server: Sip EXpress router (0.8.12 (i386/linux)) Content-Length: 0 Warning: 392 198.212.169.252:5060 "Noisy feedback tells: pid=1975 req_src_ip=216.87.144.196 req_src_port=54864 in_uri=sip:9723937976@198.212.169.252:5060 out_uri=sip:9723937976@named.com via_cnt==1"
================================================================================
SIP MESSAGE 14 216.87.144.196:54864(PSTN) -> 198.212.169.252:5060(Incoming) UDP Frame 16 11/Jan/04 14:04:38.9372 TimeFromPreviousSipFrame=0.0139 TimeFromStart=10.6097 ACK sip:9723937976@198.212.169.252:5060 SIP/2.0 Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252;tag=0007ebcdcd32003c6e0e395f-1ba5a1f2 Date: Sun, 11 Jan 2004 20:04:36 GMT Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 Route: sip:9723937976@66.228.44.212:5060 Max-Forwards: 15 Content-Length: 0 CSeq: 101 ACK
================================================================================
SIP MESSAGE 15 198.212.169.13:5060(named.com) -> 66.228.44.212:5060(PHONE) UDP Frame 17 11/Jan/04 14:04:39.0930 TimeFromPreviousSipFrame=0.1558 TimeFromStart=10.7654 CANCEL sip:9723937976@66.228.44.212:5060 SIP/2.0 Record-Route: sip:9723937976@198.212.169.13;ftag=37BD7C50-1493;lr Via: SIP/2.0/UDP 198.212.169.13;branch=z9hG4bKa1d.269f0b37.0 Via: SIP/2.0/UDP 198.212.169.252;branch=z9hG4bKa1d.eaf3b226.0 Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252 Date: Sun, 11 Jan 2004 20:04:36 GMT Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 CSeq: 101 CANCEL Max-Forwards: 13 Timestamp: 1073851487 Content-Length: 0
================================================================================
SIP MESSAGE 16 198.212.169.13:5060(named.com) -> 198.212.169.252:5060(Incoming) UDP Frame 18 11/Jan/04 14:04:39.0941 TimeFromPreviousSipFrame=0.0011 TimeFromStart=10.7666 SIP/2.0 200 cancelling Via: SIP/2.0/UDP 198.212.169.252;branch=z9hG4bKa1d.eaf3b226.0 Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252;tag=b7d3668eb496f40777f2484aa289ab96-19f9 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 CSeq: 101 CANCEL Server: Sip EXpress router (0.8.12 (i386/linux)) Content-Length: 0 Warning: 392 198.212.169.13:5060 "Noisy feedback tells: pid=6177 req_src_ip=198.212.169.252 req_src_port=5060 in_uri=sip:9723937976@named.com out_uri=sip:9723937976@66.228.44.212:5060 via_cnt==2"
================================================================================
SIP MESSAGE 17 198.212.169.13:5060(named.com) -> 198.212.169.252:5060(Incoming) UDP Frame 19 11/Jan/04 14:04:39.0941 TimeFromPreviousSipFrame=0.0000 TimeFromStart=10.7666 SIP/2.0 487 Request cancelled Via: SIP/2.0/UDP 198.212.169.252;branch=z9hG4bKa1d.eaf3b226.0 Via: SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252;tag=b7d3668eb496f40777f2484aa289ab96-19f9 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 CSeq: 101 INVITE Server: Sip EXpress router (0.8.12 (i386/linux)) Content-Length: 0 Warning: 392 198.212.169.13:5060 "Noisy feedback tells: pid=6177 req_src_ip=198.212.169.252 req_src_port=5060 in_uri=sip:9723937976@named.com out_uri=sip:9723937976@66.228.44.212:5060 via_cnt==2"
================================================================================
SIP MESSAGE 18 198.212.169.252:5060(Incoming) -> 198.212.169.13:5060(named.com) UDP Frame 20 11/Jan/04 14:04:39.0941 TimeFromPreviousSipFrame=0.0000 TimeFromStart=10.7666 ACK sip:9723937976@named.com SIP/2.0 Via: SIP/2.0/UDP 198.212.169.252;branch=z9hG4bKa1d.eaf3b226.0 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 To: sip:9723937976@198.212.169.252;tag=b7d3668eb496f40777f2484aa289ab96-19f9 CSeq: 101 ACK User-Agent: Sip EXpress router(0.8.12 (i386/linux)) Content-Length: 0
================================================================================
SIP MESSAGE 19 66.228.44.212:50238(PHONE) -> 198.212.169.13:5060(named.com) UDP Frame 21 11/Jan/04 14:04:39.1432 TimeFromPreviousSipFrame=0.0491 TimeFromStart=10.8156 SIP/2.0 200 OK Via: SIP/2.0/UDP 198.212.169.13;branch=z9hG4bKa1d.269f0b37.0,SIP/2.0/UDP 198.212.169.252;branch=z9hG4bKa1d.eaf3b226.0,SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252;tag=0007ebcdcd32003c6e0e395f-1ba5a1f2 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 Date: Sun, 11 Jan 2004 20:04:05 GMT CSeq: 101 CANCEL Server: CSCO/5 Content-Length: 0
================================================================================
SIP MESSAGE 20 66.228.44.212:50238(PHONE) -> 198.212.169.13:5060(named.com) UDP Frame 22 11/Jan/04 14:04:39.1865 TimeFromPreviousSipFrame=0.0433 TimeFromStart=10.8589 SIP/2.0 487 Request Cancelled Via: SIP/2.0/UDP 198.212.169.13;branch=z9hG4bKa1d.269f0b37.0,SIP/2.0/UDP 198.212.169.252;branch=z9hG4bKa1d.eaf3b226.0,SIP/2.0/UDP 216.87.144.196:5060 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 To: sip:9723937976@198.212.169.252;tag=0007ebcdcd32003c6e0e395f-1ba5a1f2 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 Date: Sun, 11 Jan 2004 20:04:05 GMT CSeq: 101 INVITE Server: CSCO/5 Contact: sip:9723937976@66.228.44.212:5060 Record-Route: sip:9723937976@198.212.169.13;ftag=37BD7C50-1493;lr Content-Length: 0
================================================================================
SIP MESSAGE 21 198.212.169.13:5060(named.com) -> 66.228.44.212:5060(PHONE) UDP Frame 23 11/Jan/04 14:04:39.1867 TimeFromPreviousSipFrame=0.0002 TimeFromStart=10.8591 ACK sip:9723937976@66.228.44.212:5060 SIP/2.0 Via: SIP/2.0/UDP 198.212.169.13;branch=z9hG4bKa1d.269f0b37.0 From: sip:9723935295@216.87.144.196;tag=37BD7C50-1493 Call-ID: 371B452E-43A811D8-9EC0E7B2-21580ACA@216.87.144.196 To: sip:9723937976@198.212.169.252;tag=0007ebcdcd32003c6e0e395f-1ba5a1f2 CSeq: 101 ACK User-Agent: Sip EXpress router(0.8.12 (i386/linux)) Content-Length: 0
================================================================================
List of reasons 2 traced packets out of 23 in scenario were not included. 21 included. [2] Sip Packet Filtered by callid Sip Message Descriptor was Truncated. An Extra line with full msg descriptor was added. Current gapwidth=23. Set gapwidth to 48 to avoid truncation: -gap:48 or Disable Adding of Extra line by: -description:0 ================================================================================
At 10:40 PM 1/11/2004, Greg Fausak wrote:
I have a hard time articulating my real question :-)
What I was asking was :
As long as I record route an INVITE, does that make everything else record-routed (meaning that I pick it up with the loose_route())?
After an INVITE, which initiated a call, was record-routed (proxy inserted Record_route using record_route()), subsequent SIP requests belonging to the same call (BYE typically) must take the same path. That is accomplished as follows: UAs must put record-routing information collected using INVITE in Route header fields of the BYE and proxy servers must forward the request using this information (as opposed to executing some other routing logic.) SER implements this with the action loose_route().
Note that CANCEL takes the same path but not because of record-routing. Routing information has not been recorded yet before 200 came back. There is other way to keep CANCEL in the same path as INVITE. All SIP elements are supposed to remember INVITE transaction until finished and if a CANCEL comes, send it to the same adress to which they sent INVITE.
The answer is no, you still have to route calls...loose_route() doesn't pick up everything.
Anyway, here is a packet trace from a call.
- Inbound, through a PSTN.
- Routed to the UA.
- The caller hangs up, causing a cancel.
Does the trace look right? In particular, the CANCELing 200 message and the cancelled 487...is that the way it is supposed to look?
yes, the attached call flow seems correct to me.
Some other example call-flows in IETF documents may look slighlty different but that's not normative. Particularly, the 487 may be forwarded from downstream (as opposed to generating them localy by proxy) but that would add extra latency if downstream UAS becomes unresponsive.
-jiri
Juha Heinanen wrote:
Maxim Sobolev writes:
Well, IMO absence or presence of tag in the To header field should be the definite difference between the two. INVITE which creates a dialg would be To-tag-less, while one that refreshes a dialog would usually have one. And if my memory serves according to the RFC INVITE is the only type of message which can create a dialog.
also subscribe and even notify can create a dialog.
I said "according to the standard". ;)
Nevertheless, absence/presence of To tag rule would likely apply to any other requests creating a dialog.
-Maxim
12.1 Creation of a Dialog
Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2xx and 101-199 responses with a To tag, where the request was ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ INVITE, will establish a dialog. A dialog established by a non-final ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ response to a request is in the "early" state and it is called an early dialog. Extensions MAY define other means for creating dialogs. Section 13 gives more details that are specific to the INVITE method. Here, we describe the process for creation of dialog state that is not dependent on the method.
UAs MUST assign values to the dialog ID components as described below.
On 03-01 20:10, Maxim Sobolev wrote:
Juha Heinanen wrote:
Maxim Sobolev writes:
Well, IMO absence or presence of tag in the To header field should be the definite difference between the two. INVITE which creates a dialg would be To-tag-less, while one that refreshes a dialog would usually have one. And if my memory serves according to the RFC INVITE is the only type of message which can create a dialog.
also subscribe and even notify can create a dialog.
I said "according to the standard". ;)
"The nice thing about standards is that there are so many to choose from."
I think this famous quote of Andrew S. Tannenbaum fits in perfectly here ;-).
Jan.
On 03-01 19:34, Maxim Sobolev wrote:
Jan Janak wrote:
Yes, you are right, I confused two things -- target refreshers are not related to record-routing, they update just remote target, thanks for pointing this out.
Anyway, you still don't know if message FOOBAR creates dialog.
Well, IMO absence or presence of tag in the To header field should be the definite difference between the two. INVITE which creates a dialg would be To-tag-less, while one that refreshes a dialog would usually have one. And if my memory serves according to the RFC INVITE is the only type of message which can create a dialog.
SUBSCRIBE messages also create dialogs. To tags probably could be used to distinguish such requests, nothing that would prohibit that comes on my mind right now.
Jan.
-
Greg Fausak -
Jan Janak -
Jiri Kuthan -
Juha Heinanen -
Maxim Sobolev