[OpenSER-Users] 答复: how to configure to support PRACK

[Iñaki Baz Castillo]

2008/6/4, Steven.Wu at teleca.com <Steven.Wu at teleca.com>:

> Hi Iñaki,

Hi Steven, for next time please mantain the thread in the maillist ;)

See inline:


> At first, I repied the PRACK without Route header but contian the to tag.
> I added the Route header after receive your opinion. But also failed.
> I attached my SIP message, could you please take a look them and give me
> some suggestion?

First of all, do you mean that you added the Route in the UAC? are you
programming the UAC?




> UDP Data send to: 10.57.39.120:5060

This INVITE goes to the proxy: 10.57.39.120

> INVITE sip:1141 at 10.57.39.120 SIP/2.0
> Via: SIP/2.0/UDP 10.57.39.33:5060
> From: sip:6846 at 10.57.39.120;tag=032baj647
> To: sip:1141 at 10.57.39.120
> Call-ID: asdbasdb3-asdb552
> CSeq: 899 INVITE
> Contact: sip:6846 at 10.57.39.33
> Max-Forwards: 70
> Content-Type: application/sdp
> Expires: 180
> Accept-Contact: *;+mckoppa
> Supported: precondition, 100Rel
> Require: precondition
> Content-Length: 392
> v=0
> o=Inviter2007 63241204263093750 132223800 IN IP4 10.57.39.33
> s=-
> c=IN IP4 10.57.39.33
> t=0 0
> m=audio 5000 RTP/AVP 106 8 0
> a=sendrecv
> a=rtpmap:106 AMR/8000
> a=ptime:160
> a=maxptime:200
> a=fmtp:106 octet-align=1; mode-set=7
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=curr:qos local none
> a=curr:qos remote none
> a=des:qos mandatory local sendrecv
> a=des:qos none remote sendrecv



> UDP Data received from: 10.57.39.120:5060

The proxy replies.

> SIP/2.0 183 Session Progress
> Record-Route: <sip:10.57.39.120;lr=on>

This Record-Route forces the UAC to include a "Route" header with same
value and send there future *in-dialog* requests.

> Via: SIP/2.0/UDP 10.57.39.33:5060
> Require: 100Rel
> To: <sip:1141 at 10.57.39.120>;tag=53m9f85odqq1uld83vs6
> Contact: <sip:0y9N9S0dFpYtlSrLGwwF at 10.57.39.114>

Note that the UAS location is 10.57.39.114 so future **in-dialog**
requests MUST have this IP 10.57.39.114 in the RURI and NOT the proxy
IP.

> From: <sip:6846 at 10.57.39.120>;tag=032baj647
> Supported: 100Rel,precondition
> RSeq: 2956138
> Call-ID: asdbasdb3-asdb552
> CSeq: 899 INVITE
> Allow:
> UPDATE,PRACK,SUBSCRIBE,REFER,NOTIFY,INVITE,ACK,CANCEL,OPTIONS,BYE
> Content-Type: application/sdp
> Content-Length: 465
> v=0
> o=1141 63380817057795000 63380817057795000 IN IP4 10.57.39.114
> s=-
> c=IN IP4 10.57.39.114
> t=0 0
> m=audio 5000 RTP/AVP 106 8 0
> a=sendrecv
> a=curr:qos local sendrecv
> a=curr:qos remote none
> a=des:qos mandatory local sendrecv
> a=des:qos mandatory remote sendrecv
> a=conf:qos remote sendrecv
> a=rtcp:5001 IN IP4 10.57.39.114
> a=rtpmap:106 AMR/8000
> a=ptime:160
> a=maxptime:200
> a=fmtp:106 octet-align=1; mode-set=7
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
>



> UDP Data send to: 10.57.39.120:5060

This is an in-dialog message (it has "To" tag) but the RURI is not the
received Contact (10.57.39.114). It's the proxy IP, why??? this is
completely incorrect. An in-dialog request must have in the RURI the
URI received in the 183 Contact.
And if the in-dialog request has a "Route" header it must be send to
that location. This is how loose routing works.


> PRACK sip:1141 at 10.57.39.120 SIP/2.0
> Via: SIP/2.0/UDP 10.57.39.33:5060
> From: sip:6846 at 10.57.39.120;tag=032baj647
> To: sip:1141 at 10.57.39.120;tag=53m9f85odqq1uld83vs6
> Call-ID: asdbasdb3-asdb552
> CSeq: 89951 PRACK
> Contact: sip:6846 at 10.57.39.33
> Max-Forwards: 70
> Route: <sip:10.57.39.120;lr=on>
> Content-Type: application/sdp
> Expires: 180
> Accept-Contact: *;+mckoppa
> Supported: precondition, 100Rel
> Require: precondition
> RAck:2956138 899 INVITE
> Content-Length: 278
> v=0
> o=Inviter2007 63241204263093750 132223801 IN IP4 10.57.39.33
> s=-
> c=IN IP4 10.57.39.33
> t=0 0
> m=audio 5000 RTP/AVP 106
> a=rtpmap:106 AMR/8000
> a=curr:qos local sendrecv
> a=curr:qos remote sendrecv
> a=des:qos mandatory local sendrecv
> a=des:qos mandatory remote sendrecv
>
>
> If added a route rule 'if ( is_method("PRACK") ) { t_relay(); exit;} ' ,
> I'll receive the 483 response.
> Otherwise, receive 404 Not here

It makes sense 100%. It's an error in the RURI of your PRACK.

Please, read again http://tools.ietf.org/html/rfc3261#section-12.2

Regards.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>