26 Jun
2003
26 Jun
'03
3:59 p.m.
Hi,
is ser supporting the SIP Request PRACK ? I get this Requests when i am
forwarding an incoming call from a cisco router back to it (with an
other number) --> the destination telephone rings but i do not hear the
signals (ringing) on my calling phone. When the called phone accepts the
call then everything works fine.
In more detail:
The cisco router sends 2 PRACK Requests:
1. to the phone that is the destination of the forward (after
forwarding)
2. to the phone with the forwarding set
But not to the phone which initialises the call.
Regards,
Reinhard
26 Jun
26 Jun
4:18 p.m.
I don't think the problem is on SER side, SER supports PRACKs transparently.
Feel free to send us network dumps so that we look at the problems you have.
-Andy
At 02:59 PM 6/26/2003, Reinhard Hainz wrote:
Hi,
is ser supporting the SIP Request PRACK ? I get this Requests when i am forwarding an
incoming call from a cisco router back to it (with an other number) à the destination
telephone rings but i do not hear the signals (ringing) on my calling phone. When the
called phone accepts the call then everything works fine.
In more detail:
The cisco router sends 2 PRACK Requests:
* to the phone that is the destination of the forward (after forwarding)
* to the phone with the forwarding set
But not to the phone which initialises the call.
Regards,
Reinhard
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Andy Blen
iptel.org Services
27 Jun
27 Jun
12:06 p.m.
New subject: AW: [Serusers] PRACK
Hi,
the situation is more complicated.
The environemet:
A ... a "traditional" phone in the PSTN world
B ... an other "traditional" phone in PSTN
C ... a cisco gw connecting PSTN to IP (SIP)
D ... a SIP-Server (ser)
E ... a phone number configured in ser, that is forwared to the number
of B (using URI rewriting from ser)
The request flow is as follows:
1. A is connected (over PSTN) to C
2. C sends an INVITE to D (URI: E - this is the To-Header, too)
3. D rewrites the INVITE for E to an INVITE to B
4. D sends an INVITE to C for B (E is the record-route)
5. C sends both E a PRACK
6. D sends itself a PRACK for B (but i am not forwarding it)
The question is - why does cisco send this PRACK at all. Wenn I use the
same configuration which IP-Phones only, then no PRACK are send.
At 5. the phone B rings (but no ring tone at A), and after accepting the
call at B the call is established and works.
Regards,
Reinhard
-----Ursprüngliche Nachricht-----
Von: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] Im
Auftrag von Andy Blen
Gesendet: Donnerstag, 26. Juni 2003 15:18
An: Reinhard Hainz; serusers(a)lists.iptel.org
Betreff: Re: [Serusers] PRACK
I don't think the problem is on SER side, SER supports PRACKs
transparently.
Feel free to send us network dumps so that we look at the problems you
have.
-Andy
At 02:59 PM 6/26/2003, Reinhard Hainz wrote:
Hi,
is ser supporting the SIP Request PRACK ? I get this Requests when i am
forwarding
an incoming call from a cisco router back to it (with an
other number) à the destination telephone rings but i do not hear the
signals (ringing) on my calling phone. When the called phone accepts the
call then everything works fine.
In more detail:
The cisco router sends 2 PRACK Requests:
* to the phone that is the destination of the forward (after
forwarding)
* to the phone with the forwarding set
But not to the phone which initialises the call.
Regards,
Reinhard
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Andy Blen
iptel.org Services
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
28 Jun
28 Jun
1:31 a.m.
New subject: AW: [Serusers] PRACK
At 11:06 AM 6/27/2003, Reinhard Hainz wrote:
Hi,
the situation is more complicated.
The environemet:
A ... a "traditional" phone in the PSTN world
B ... an other "traditional" phone in PSTN
C ... a cisco gw connecting PSTN to IP (SIP)
D ... a SIP-Server (ser)
E ... a phone number configured in ser, that is forwared to the number
of B (using URI rewriting from ser)
The request flow is as follows:
1. A is connected (over PSTN) to C
2. C sends an INVITE to D (URI: E - this is the To-Header, too)
3. D rewrites the INVITE for E to an INVITE to B
4. D sends an INVITE to C for B (E is the record-route)
5. C sends both E a PRACK
6. D sends itself a PRACK for B (but i am not forwarding it)
The question is - why does cisco send this PRACK at all.
Cisco uses PRACK if the other party supports PRACK. With hairpinning,
when Cisco speaks to itself, it uses PRACK. The support is advertised
in Supported: 100rel. (We for example strip it away for snom phones
which screw up record routing if PRACK is turned on: replace("100rel,
", "");)
Wenn I use the
same configuration which IP-Phones only, then no PRACK are send.
That's because the phone does not advertise PRACK support.
At 5. the phone B rings (but no ring tone at A), and
after accepting the
call at B the call is established and works.
Hard to guess why without seeing the call flows, in my opinion the common
suspect is Cisco gatway here. Perhaps it gets confused by combination of
hairpinning and PRACK. If I was you, I would at least try stripping 100rel
away just out of curiosity to see if PRACK removal happens to avoid the bug.
Send us network dumps if you don't move ahead -- we may try finding
oddities too.
-Jiri
30 Jun
30 Jun
11:49 a.m.
New subject: AW: AW: [Serusers] PRACK
Hi,
Ok, removeing 100rel does not solve my problem.
here the call flow (tcpdump - I replaced any customer related stuff):
10:25:46.000003 CISCO-GW.52786 > SER-SERVER.5060: udp 1036 [tos 0x68]
Eh.(.......u>c.1..<m.2.....mINVITE.sip:01xxxxxxx@SER-SERVER:5060.SIP/2.0
..Via:.SIP/2.0/UDP..IP-OF-CISCO-GW:5060..From:.<sip:0664xxxxxxx@IP-OF-CI
SCO-GW>;tag=43160C68-15DE..To:.<sip:01xxxxxxx@SER-SERVER>..Date:.Mon,.30
.Jun.2003.08:25:46.GMT..Call-ID:.4850167A-AA0B11D7-BB1AD53F-7B45CE33@IP-
OF-CISCO-GW..Supported:.timer,100rel..Min-SE:..1800..Cisco-Guid:.1213088
105-2852852183-3138901311-2068172339..User-Agent:.Cisco-SIPGateway/IOS-1
2.x..Allow:.INVITE,.OPTIONS,.BYE,.CANCEL,.ACK,.PRACK,.COMET,.REFER,.SUBS
CRIBE,.NOTIFY,.INFO..CSeq:.101.INVITE..Max-Forwards:.6..Remote-Party-ID:
.<sip:0664xxxxxxx@IP-OF-CISCO-GW>;party=calling;screen=yes;privacy=off..
Timestamp:.1056961546..Contact:.<sip:0664xxxxxxx@IP-OF-CISCO-GW:5060>..E
xpires:.180..Allow-Events:.telephone-event..Content-Type:.application/sd
p..Content-Length:.250....v=0..o=CiscoSystemsSIP-GW-UserAgent.3677.7191.
IN.IP4.IP-OF-CISCO-GW..s=SIP.Call..c=IN.IP4.IP-OF-CISCO-GW..t=0.0..m=aud
io.17580.RTP/AVP.18.3.8.0..a=rtpmap:18.G729/8000..a=fmtp:18.annexb=no..a
=rtpmap:3.GSM/8000..a=rtpmap:8.PCMA/8000..a=rtpmap:0.PCMU/8000..
10:25:46.119212 SER-SERVER.5060 > CISCO-GW.5060: udp 508 (DF) [tos 0x10]
E.....@.@.<...<m>c.1......&.SIP/2.0.100.trying.--.your.call.is.important
.to.us..Via:.SIP/2.0/UDP..IP-OF-CISCO-GW:5060..From:.<sip:0664xxxxxxx@IP
-OF-CISCO-GW>;tag=43160C68-15DE..To:.<sip:01xxxxxxx@SER-SERVER>..Call-ID
:.4850167A-AA0B11D7-BB1AD53F-7B45CE33@IP-OF-CISCO-GW..CSeq:.101.INVITE..
Server:.Sip.EXpress.router.(0.8.10.(i386/linux))..Content-Length:.0..War
ning:.392.IP-OF-SER-SERVER:5060."Noisy.feedback.tells:.pid=11070.req_src
_ip=IP-OF-CISCO-GW.in_uri=sip:01xxxxxxx@SER-SERVER:5060.out_uri=sip:0599
99xxxx(a)SER-SERVER.via_cnt==1"quot;....
10:25:46.238277 SER-SERVER.5060 > CISCO-GW.5060: udp 1276 (DF) [tos
0x10]
E.....@.@.9...<m>c.1.......{INVITE.sip:059999xxxx@PSTN.SIP/2.0..Record-R
oute:.<sip:059999xxxx@IP-OF-SER-SERVER;branch=0>..Record-Route:.<sip:01x
xxxxxx@IP-OF-SER-SERVER;branch=0>..Via:.SIP/2.0/UDP.IP-OF-SER-SERVER;bra
nch=z9hG4bK202c.d14ca635.0..Via:.SIP/2.0/UDP.IP-OF-SER-SERVER;branch=z9h
G4bK202c.c14ca635.0..Via:.SIP/2.0/UDP..IP-OF-CISCO-GW:5060..From:.<sip:0
664xxxxxxx@IP-OF-CISCO-GW>;tag=43160C68-15DE..To:.<sip:01xxxxxxx@SER-SER
VER>..Date:.Mon,.30.Jun.2003.08:25:46.GMT..Call-ID:.4850167A-AA0B11D7-BB
1AD53F-7B45CE33@IP-OF-CISCO-GW..Supported:.timer..Min-SE:..1800..Cisco-G
uid:.1213088105-2852852183-3138901311-2068172339..User-Agent:.Cisco-SIPG
ateway/IOS-12.x..Allow:.INVITE,.OPTIONS,.BYE,.CANCEL,.ACK,.PRACK,.COMET,
.REFER,.SUBSCRIBE,.NOTIFY,.INFO..CSeq:.101.INVITE..Max-Forwards:.4..Remo
te-Party-ID:.<sip:0664xxxxxxx@IP-OF-CISCO-GW>;party=calling;screen=yes;p
rivacy=off..Timestamp:.1056961546..Contact:.<sip:0664xxxxxxx@IP-OF-CISCO
-GW:5060>..Expires:.180..Allow-Events:.telephone-event..Content-Type:.ap
plication/sdp..Content-Length:.250..P-hint:.INODE-TO-PSTN....v=0..o=Cisc
oSystemsSIP-GW-UserAgent.3677.7191.IN.IP4.IP-OF-CISCO-GW..s=SIP.Call..c=
IN.IP4.IP-OF-CISCO-GW..t=0.0..m=audio.17580.RTP/AVP.18.3.8.0..a=rtpmap:1
8.G729/8000..a=fmtp:18.annexb=no..a=rtpmap:3.GSM/8000..a=rtpmap:8.PCMA/8
000..a=rtpmap:0.PCMU/8000..
10:25:46.250827 CISCO-GW.5060 > SER-SERVER.5060: udp 504 [tos 0x68]
Eh...M.....<>c.1..<m......t3SIP/2.0.100.Trying..Via:.SIP/2.0/UDP.IP-OF-S
ER-SERVER;branch=z9hG4bK202c.d14ca635.0,SIP/2.0/UDP.IP-OF-SER-SERVER;bra
nch=z9hG4bK202c.c14ca635.0,SIP/2.0/UDP..IP-OF-CISCO-GW:5060..From:.<sip:
0664xxxxxxx@IP-OF-CISCO-GW>;tag=43160C68-15DE..To:.<sip:01xxxxxxx@SER-SE
RVER>;tag=43160D64-2631..Date:.Mon,.30.Jun.2003.08:25:46.GMT..Call-ID:.4
850167A-AA0B11D7-BB1AD53F-7B45CE33@IP-OF-CISCO-GW..Timestamp:.1056961546
..Server:.Cisco-SIPGateway/IOS-12.x..CSeq:.101.INVITE..Allow-Events:.tel
ephone-event..Content-Length:.0....
10:25:48.635836 CISCO-GW.5060 > SER-SERVER.5060: udp 774 [tos 0x68]
Eh.".N.....->c.1..<m........SIP/2.0.183.Session.Progress..Via:.SIP/2.0/U
DP.IP-OF-SER-SERVER;branch=z9hG4bK202c.d14ca635.0,SIP/2.0/UDP.IP-OF-SER-
SERVER;branch=z9hG4bK202c.c14ca635.0,SIP/2.0/UDP..IP-OF-CISCO-GW:5060..F
rom:.<sip:0664xxxxxxx@IP-OF-CISCO-GW>;tag=43160C68-15DE..To:.<sip:01xxxx
xxx@SER-SERVER>;tag=43160D64-2631..Date:.Mon,.30.Jun.2003.08:25:46.GMT..
Call-ID:.4850167A-AA0B11D7-BB1AD53F-7B45CE33@IP-OF-CISCO-GW..Timestamp:.
1056961546..Server:.Cisco-SIPGateway/IOS-12.x..CSeq:.101.INVITE..Allow-E
vents:.telephone-event..Content-Type:.application/sdp..Content-Dispositi
on:.session;handling=required..Content-Length:.179....v=0..o=CiscoSystem
sSIP-GW-UserAgent.5940.9871.IN.IP4.IP-OF-CISCO-GW..s=SIP.Call..c=IN.IP4.
IP-OF-CISCO-GW..t=0.0..m=audio.17160.RTP/AVP.18..a=rtpmap:18.G729/8000..
a=fmtp:18.annexb=no..
10:25:48.636102 SER-SERVER.5060 > CISCO-GW.5060: udp 659 (DF) [tos 0x10]
E.....@.@.<G..<m>c.1......u.SIP/2.0.183.Session.Progress..Via:SIP/2.0/UD
P..IP-OF-CISCO-GW:5060..From:.<sip:0664xxxxxxx@IP-OF-CISCO-GW>;tag=43160
C68-15DE..To:.<sip:01xxxxxxx@SER-SERVER>;tag=43160D64-2631..Date:.Mon,.3
0.Jun.2003.08:25:46.GMT..Call-ID:.4850167A-AA0B11D7-BB1AD53F-7B45CE33@IP
-OF-CISCO-GW..Timestamp:.1056961546..Server:.Cisco-SIPGateway/IOS-12.x..
CSeq:.101.INVITE..Allow-Events:.telephone-event..Content-Type:.applicati
on/sdp..Content-Disposition:.session;handling=required..Content-Length:.
179....v=0..o=CiscoSystemsSIP-GW-UserAgent.5940.9871.IN.IP4.IP-OF-CISCO-
GW..s=SIP.Call..c=IN.IP4.IP-OF-CISCO-GW..t=0.0..m=audio.17160.RTP/AVP.18
..a=rtpmap:18.G729/8000..a=fmtp:18.annexb=no..
CANCEL
Reinhard
-----Ursprüngliche Nachricht-----
Von: Jiri Kuthan [mailto:jiri@iptel.org]
Gesendet: Samstag, 28. Juni 2003 00:31
An: Reinhard Hainz; 'Andy Blen'; serusers(a)lists.iptel.org
Betreff: Re: AW: [Serusers] PRACK
At 11:06 AM 6/27/2003, Reinhard Hainz wrote:
Hi,
the situation is more complicated.
The environemet:
A ... a "traditional" phone in the PSTN world
B ... an other "traditional" phone in PSTN
C ... a cisco gw connecting PSTN to IP (SIP)
D ... a SIP-Server (ser)
E ... a phone number configured in ser, that is forwared to the number
of B (using URI rewriting from ser)
The request flow is as follows:
1. A is connected (over PSTN) to C
2. C sends an INVITE to D (URI: E - this is the To-Header, too)
3. D rewrites the INVITE for E to an INVITE to B
4. D sends an INVITE to C for B (E is the record-route)
5. C sends both E a PRACK
6. D sends itself a PRACK for B (but i am not forwarding it)
The question is - why does cisco send this PRACK at all.
Cisco uses PRACK if the other party supports PRACK. With hairpinning,
when Cisco speaks to itself, it uses PRACK. The support is advertised
in Supported: 100rel. (We for example strip it away for snom phones
which screw up record routing if PRACK is turned on: replace("100rel,
", "");)
Wenn I use the
same configuration which IP-Phones only, then no PRACK are send.
That's because the phone does not advertise PRACK support.
At 5. the phone B rings (but no ring tone at A), and
after accepting
the
call at B the call is established and works.
Hard to guess why without seeing the call flows, in my opinion the
common
suspect is Cisco gatway here. Perhaps it gets confused by combination of
hairpinning and PRACK. If I was you, I would at least try stripping
100rel
away just out of curiosity to see if PRACK removal happens to avoid the
bug.
Send us network dumps if you don't move ahead -- we may try finding
oddities too.
-Jiri
1:23 p.m.
New subject: AW: AW: [Serusers] PRACK
I think that SIP-Phones (Cisco 79xx, ATA186, ...) take a SIP Answer 183
(Session Progess) as 180 (Ringing) and the cisco gw does not do this.
Every call initiated by our cisco gw sends 183 (never 180). With
hairpinning we send 183 (comming from the gw) back to it, but the gw
does not interpret this as Ringing.
-----Ursprüngliche Nachricht-----
Von: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] Im
Auftrag von Reinhard Hainz
Gesendet: Montag, 30. Juni 2003 10:50
An: 'Jiri Kuthan'; 'Andy Blen'; serusers(a)lists.iptel.org
Betreff: AW: AW: [Serusers] PRACK
Hi,
Ok, removeing 100rel does not solve my problem.
here the call flow (tcpdump - I replaced any customer related stuff):
10:25:46.000003 CISCO-GW.52786 > SER-SERVER.5060: udp 1036 [tos 0x68]
Eh.(.......u>c.1..<m.2.....mINVITE.sip:01xxxxxxx@SER-SERVER:5060.SIP/2.0
..Via:.SIP/2.0/UDP..IP-OF-CISCO-GW:5060..From:.<sip:0664xxxxxxx@IP-OF-CI
SCO-GW>;tag=43160C68-15DE..To:.<sip:01xxxxxxx@SER-SERVER>..Date:.Mon,.30
.Jun.2003.08:25:46.GMT..Call-ID:.4850167A-AA0B11D7-BB1AD53F-7B45CE33@IP-
OF-CISCO-GW..Supported:.timer,100rel..Min-SE:..1800..Cisco-Guid:.1213088
105-2852852183-3138901311-2068172339..User-Agent:.Cisco-SIPGateway/IOS-1
2.x..Allow:.INVITE,.OPTIONS,.BYE,.CANCEL,.ACK,.PRACK,.COMET,.REFER,.SUBS
CRIBE,.NOTIFY,.INFO..CSeq:.101.INVITE..Max-Forwards:.6..Remote-Party-ID:
.<sip:0664xxxxxxx@IP-OF-CISCO-GW>;party=calling;screen=yes;privacy=off..
Timestamp:.1056961546..Contact:.<sip:0664xxxxxxx@IP-OF-CISCO-GW:5060>..E
xpires:.180..Allow-Events:.telephone-event..Content-Type:.application/sd
p..Content-Length:.250....v=0..o=CiscoSystemsSIP-GW-UserAgent.3677.7191.
IN.IP4.IP-OF-CISCO-GW..s=SIP.Call..c=IN.IP4.IP-OF-CISCO-GW..t=0.0..m=aud
io.17580.RTP/AVP.18.3.8.0..a=rtpmap:18.G729/8000..a=fmtp:18.annexb=no..a
=rtpmap:3.GSM/8000..a=rtpmap:8.PCMA/8000..a=rtpmap:0.PCMU/8000..
10:25:46.119212 SER-SERVER.5060 > CISCO-GW.5060: udp 508 (DF) [tos 0x10]
E.....@.@.<...<m>c.1......&.SIP/2.0.100.trying.--.your.call.is.important
.to.us..Via:.SIP/2.0/UDP..IP-OF-CISCO-GW:5060..From:.<sip:0664xxxxxxx@IP
-OF-CISCO-GW>;tag=43160C68-15DE..To:.<sip:01xxxxxxx@SER-SERVER>..Call-ID
:.4850167A-AA0B11D7-BB1AD53F-7B45CE33@IP-OF-CISCO-GW..CSeq:.101.INVITE..
Server:.Sip.EXpress.router.(0.8.10.(i386/linux))..Content-Length:.0..War
ning:.392.IP-OF-SER-SERVER:5060."Noisy.feedback.tells:.pid=11070.req_src
_ip=IP-OF-CISCO-GW.in_uri=sip:01xxxxxxx@SER-SERVER:5060.out_uri=sip:0599
99xxxx(a)SER-SERVER.via_cnt==1"quot;....
10:25:46.238277 SER-SERVER.5060 > CISCO-GW.5060: udp 1276 (DF) [tos
0x10]
E.....@.@.9...<m>c.1.......{INVITE.sip:059999xxxx@PSTN.SIP/2.0..Record-R
oute:.<sip:059999xxxx@IP-OF-SER-SERVER;branch=0>..Record-Route:.<sip:01x
xxxxxx@IP-OF-SER-SERVER;branch=0>..Via:.SIP/2.0/UDP.IP-OF-SER-SERVER;bra
nch=z9hG4bK202c.d14ca635.0..Via:.SIP/2.0/UDP.IP-OF-SER-SERVER;branch=z9h
G4bK202c.c14ca635.0..Via:.SIP/2.0/UDP..IP-OF-CISCO-GW:5060..From:.<sip:0
664xxxxxxx@IP-OF-CISCO-GW>;tag=43160C68-15DE..To:.<sip:01xxxxxxx@SER-SER
VER>..Date:.Mon,.30.Jun.2003.08:25:46.GMT..Call-ID:.4850167A-AA0B11D7-BB
1AD53F-7B45CE33@IP-OF-CISCO-GW..Supported:.timer..Min-SE:..1800..Cisco-G
uid:.1213088105-2852852183-3138901311-2068172339..User-Agent:.Cisco-SIPG
ateway/IOS-12.x..Allow:.INVITE,.OPTIONS,.BYE,.CANCEL,.ACK,.PRACK,.COMET,
.REFER,.SUBSCRIBE,.NOTIFY,.INFO..CSeq:.101.INVITE..Max-Forwards:.4..Remo
te-Party-ID:.<sip:0664xxxxxxx@IP-OF-CISCO-GW>;party=calling;screen=yes;p
rivacy=off..Timestamp:.1056961546..Contact:.<sip:0664xxxxxxx@IP-OF-CISCO
-GW:5060>..Expires:.180..Allow-Events:.telephone-event..Content-Type:.ap
plication/sdp..Content-Length:.250..P-hint:.INODE-TO-PSTN....v=0..o=Cisc
oSystemsSIP-GW-UserAgent.3677.7191.IN.IP4.IP-OF-CISCO-GW..s=SIP.Call..c=
IN.IP4.IP-OF-CISCO-GW..t=0.0..m=audio.17580.RTP/AVP.18.3.8.0..a=rtpmap:1
8.G729/8000..a=fmtp:18.annexb=no..a=rtpmap:3.GSM/8000..a=rtpmap:8.PCMA/8
000..a=rtpmap:0.PCMU/8000..
10:25:46.250827 CISCO-GW.5060 > SER-SERVER.5060: udp 504 [tos 0x68]
Eh...M.....<>c.1..<m......t3SIP/2.0.100.Trying..Via:.SIP/2.0/UDP.IP-OF-S
ER-SERVER;branch=z9hG4bK202c.d14ca635.0,SIP/2.0/UDP.IP-OF-SER-SERVER;bra
nch=z9hG4bK202c.c14ca635.0,SIP/2.0/UDP..IP-OF-CISCO-GW:5060..From:.<sip:
0664xxxxxxx@IP-OF-CISCO-GW>;tag=43160C68-15DE..To:.<sip:01xxxxxxx@SER-SE
RVER>;tag=43160D64-2631..Date:.Mon,.30.Jun.2003.08:25:46.GMT..Call-ID:.4
850167A-AA0B11D7-BB1AD53F-7B45CE33@IP-OF-CISCO-GW..Timestamp:.1056961546
..Server:.Cisco-SIPGateway/IOS-12.x..CSeq:.101.INVITE..Allow-Events:.tel
ephone-event..Content-Length:.0....
10:25:48.635836 CISCO-GW.5060 > SER-SERVER.5060: udp 774 [tos 0x68]
Eh.".N.....->c.1..<m........SIP/2.0.183.Session.Progress..Via:.SIP/2.0/U
DP.IP-OF-SER-SERVER;branch=z9hG4bK202c.d14ca635.0,SIP/2.0/UDP.IP-OF-SER-
SERVER;branch=z9hG4bK202c.c14ca635.0,SIP/2.0/UDP..IP-OF-CISCO-GW:5060..F
rom:.<sip:0664xxxxxxx@IP-OF-CISCO-GW>;tag=43160C68-15DE..To:.<sip:01xxxx
xxx@SER-SERVER>;tag=43160D64-2631..Date:.Mon,.30.Jun.2003.08:25:46.GMT..
Call-ID:.4850167A-AA0B11D7-BB1AD53F-7B45CE33@IP-OF-CISCO-GW..Timestamp:.
1056961546..Server:.Cisco-SIPGateway/IOS-12.x..CSeq:.101.INVITE..Allow-E
vents:.telephone-event..Content-Type:.application/sdp..Content-Dispositi
on:.session;handling=required..Content-Length:.179....v=0..o=CiscoSystem
sSIP-GW-UserAgent.5940.9871.IN.IP4.IP-OF-CISCO-GW..s=SIP.Call..c=IN.IP4.
IP-OF-CISCO-GW..t=0.0..m=audio.17160.RTP/AVP.18..a=rtpmap:18.G729/8000..
a=fmtp:18.annexb=no..
10:25:48.636102 SER-SERVER.5060 > CISCO-GW.5060: udp 659 (DF) [tos 0x10]
E.....@.@.<G..<m>c.1......u.SIP/2.0.183.Session.Progress..Via:SIP/2.0/UD
P..IP-OF-CISCO-GW:5060..From:.<sip:0664xxxxxxx@IP-OF-CISCO-GW>;tag=43160
C68-15DE..To:.<sip:01xxxxxxx@SER-SERVER>;tag=43160D64-2631..Date:.Mon,.3
0.Jun.2003.08:25:46.GMT..Call-ID:.4850167A-AA0B11D7-BB1AD53F-7B45CE33@IP
-OF-CISCO-GW..Timestamp:.1056961546..Server:.Cisco-SIPGateway/IOS-12.x..
CSeq:.101.INVITE..Allow-Events:.telephone-event..Content-Type:.applicati
on/sdp..Content-Disposition:.session;handling=required..Content-Length:.
179....v=0..o=CiscoSystemsSIP-GW-UserAgent.5940.9871.IN.IP4.IP-OF-CISCO-
GW..s=SIP.Call..c=IN.IP4.IP-OF-CISCO-GW..t=0.0..m=audio.17160.RTP/AVP.18
..a=rtpmap:18.G729/8000..a=fmtp:18.annexb=no..
CANCEL
Reinhard
-----Ursprüngliche Nachricht-----
Von: Jiri Kuthan [mailto:jiri@iptel.org]
Gesendet: Samstag, 28. Juni 2003 00:31
An: Reinhard Hainz; 'Andy Blen'; serusers(a)lists.iptel.org
Betreff: Re: AW: [Serusers] PRACK
At 11:06 AM 6/27/2003, Reinhard Hainz wrote:
Hi,
the situation is more complicated.
The environemet:
A ... a "traditional" phone in the PSTN world
B ... an other "traditional" phone in PSTN
C ... a cisco gw connecting PSTN to IP (SIP)
D ... a SIP-Server (ser)
E ... a phone number configured in ser, that is forwared to the number
of B (using URI rewriting from ser)
The request flow is as follows:
1. A is connected (over PSTN) to C
2. C sends an INVITE to D (URI: E - this is the To-Header, too)
3. D rewrites the INVITE for E to an INVITE to B
4. D sends an INVITE to C for B (E is the record-route)
5. C sends both E a PRACK
6. D sends itself a PRACK for B (but i am not forwarding it)
The question is - why does cisco send this PRACK at all.
Cisco uses PRACK if the other party supports PRACK. With hairpinning,
when Cisco speaks to itself, it uses PRACK. The support is advertised
in Supported: 100rel. (We for example strip it away for snom phones
which screw up record routing if PRACK is turned on: replace("100rel,
", "");)
Wenn I use the
same configuration which IP-Phones only, then no PRACK are send.
That's because the phone does not advertise PRACK support.
At 5. the phone B rings (but no ring tone at A), and
after accepting
the
call at B the call is established and works.
Hard to guess why without seeing the call flows, in my opinion the
common
suspect is Cisco gatway here. Perhaps it gets confused by combination of
hairpinning and PRACK. If I was you, I would at least try stripping
100rel
away just out of curiosity to see if PRACK removal happens to avoid the
bug.
Send us network dumps if you don't move ahead -- we may try finding
oddities too.
-Jiri
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
1 Jul
1 Jul
12:19 a.m.
New subject: AW: AW: [Serusers] PRACK
At 12:23 PM 6/30/2003, Reinhard Hainz wrote:
I think that SIP-Phones (Cisco 79xx, ATA186, ...) take
a SIP Answer 183
(Session Progess) as 180 (Ringing) and the cisco gw does not do this.
Every call initiated by our cisco gw sends 183 (never 180).
With our cisco gw, it depends on the final PSTN destination. We sometimes
receive 183 (our PBX, intn'l), sometimes 180 (cell phone number).
With hairpinning we send 183 (comming from the gw) back
to it, but the gw
does not interpret this as Ringing.
I retried now and both 183 and 180 worked with hairpinning. We are using
(C2600-IS5-M), Version 12.2(15)T2.
-Jiri
7821
days inactive
7825
days old
6 comments
3 participants
participants (3)
-
Andy Blen -
Jiri Kuthan -
Reinhard Hainz