3 Jan
2004
3 Jan
'04
12:14 p.m.
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.
3 Jan
3 Jan
12:24 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:34 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:41 p.m.
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
12:58 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
1:27 p.m.
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
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.
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.
11 Jan
11 Jan
4:40 p.m.
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:
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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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
================================================================================
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.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
4:56 p.m.
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.
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?
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
3 Jan
3 Jan
1:10 p.m.
Juha Heinanen wrote:
Maxim Sobolev writes:
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.
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.
1:19 p.m.
On 03-01 20:10, Maxim Sobolev wrote:
Juha Heinanen wrote:
"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.
Maxim Sobolev writes:
I said "according to the standard". ;)
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.
1:07 p.m.
On 03-01 19:34, Maxim Sobolev wrote:
Jan Janak wrote:
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.
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.
7628
days inactive
7636
days old
10 comments
5 participants
participants (5)
-
Greg Fausak -
Jan Janak -
Jiri Kuthan -
Juha Heinanen -
Maxim Sobolev