[OpenSIPS-Users] 503 reply goes to? help
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Thu Feb 12 09:00:20 CET 2009
According to RFC 3261, the defining elements for a dialog are Callid,
To-tag and From-tag. TO-uri and From-uri are obsolete .
Regards,
Bogdan
Brett Nemeroff wrote:
> I was a little confused. I was trying to explain to the operator that
> the reply doesn't have a RURI and that I send it with the same To/From
> headers they send me.
>
> I did check the headers and they are they same.. I'm going to be doing
> some more testing on this tomorrow. It's my understanding that they
> should be matching dialogs based on the to_tag and the callid, isn't
> that right? And in general, I shouldn't mess with the to/from headers,
> right?
>
> -Brett
>
>
> On Thu, Feb 12, 2009 at 1:52 AM, Bogdan-Andrei Iancu
> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> wrote:
>
> Hi Brett,
>
> Ok, more clear now :)
>
> " ...because the "To:" field doesn't match the RURI."
>
> I guess they refer at RURI from IINVITE request and TO hdr from
> reply ? If so, Both this entities are generated by UAC. The TO hdr
> from reply is the TO header from INVITE (plus the TO tag).
>
> So, can you visually check if the To tag (as uri) from INVITE is
> the same as in the 503 reply you sent ?
>
> Regards,
> Bogdan
>
>
> Brett Nemeroff wrote:
>
> Ugh! I didn't make that easy, did I.. Yes, in failure route I
> t_reply (not relay) with a 503. They ignore the REPLY, there
> is no new branch. The UAC is ignoring my REPLY and the
> operator of that device is telling me that it's because the
> "To:" field doesn't match the RURI.
>
> On Thu, Feb 12, 2009 at 1:26 AM, Bogdan-Andrei Iancu
> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>
> <mailto:bogdan at voice-system.ro
> <mailto:bogdan at voice-system.ro>>> wrote:
>
> Hi Brett,
>
>
> Brett Nemeroff wrote:
>
> All,
> I'm having an issue with a customer's nextone sbc. They
> send a
> call out, I send it to my upstream. My upstream is broken
> (separate issue althogether). They send me 183..183.. 500.
> When I get the 500, I send a 503 to the originator of the
> request (my customer)
>
> So, in failure_route you replace the received 500 with a 503
> reply, right?
>
>
> .. and they ignore the request, so I retransmit it 4-5
> times..
>
> request? you said you already received the reply....I guess you
> retransmit the reply ? ..or maybe I'm missing something.
>
> I'm not doing anything weird. I'm using t_relay for the
> 503 in
> a failure route and I'm not rewriting anything other
> than the
> original request ruri. No funny business with tags.
>
> you mean t_reply() ? I see no new branch in the flow you post.
>
> What the pseudo-trace shows is the UAC not accepting the
> 503 from
> your side, is this the issue?
>
> Regards,
> Bogdan
>
>
> During the transaction, other requests replies seem to
> work:
>
> 60.793458 62.25.18.34 -> 75.82.100.5 SIP/SDP Request:
> INVITE sip:5216161079999 at 75.82.100.5
> <mailto:sip%3A5216161079999 at 75.82.100.5>
> <mailto:sip%3A5216161079999 at 75.82.100.5
> <mailto:sip%253A5216161079999 at 75.82.100.5>>
> <mailto:sip%3A5216161079999 at 75.82.100.5
> <mailto:sip%253A5216161079999 at 75.82.100.5>
> <mailto:sip%253A5216161079999 at 75.82.100.5
> <mailto:sip%25253A5216161079999 at 75.82.100.5>>>;user=phone, with
>
> session description
>
>
> 60.796605 75.82.100.5 -> 62.25.18.34 SIP Status: 100
> Giving
> a try
>
> 60.796847 75.82.100.5 -> 202.152.59.3 SIP/SDP Request:
> INVITE sip:5216161079999 at 202.152.59.3
> <mailto:sip%3A5216161079999 at 202.152.59.3>
> <mailto:sip%3A5216161079999 at 202.152.59.3
> <mailto:sip%253A5216161079999 at 202.152.59.3>>
> <mailto:sip%3A5216161079999 at 202.152.59.3
> <mailto:sip%253A5216161079999 at 202.152.59.3>
> <mailto:sip%253A5216161079999 at 202.152.59.3
> <mailto:sip%25253A5216161079999 at 202.152.59.3>>>, with session
>
> description
>
>
> 60.822516 202.152.59.3 -> 75.82.100.5 SIP Status: 100
> Trying
>
> 60.891115 202.152.59.3 -> 75.82.100.5 SIP/SDP Status: 183
> Session Progress, with session description
>
> 60.892837 75.82.100.5 -> 62.25.18.34 SIP/SDP Status: 183
> Session Progress, with session description
>
> 60.903312 62.25.18.34 -> 75.82.100.5 SIP Request: PRACK
> sip:5216161079999 at 202.152.59.3:5060
> <http://sip:5216161079999@202.152.59.3:5060>
> <http://sip:5216161079999@202.152.59.3:5060>
> <http://sip:5216161079999@202.152.59.3:5060>
>
> 60.905058 75.82.100.5 -> 202.152.59.3 SIP Request: PRACK
> sip:5216161079999 at 202.152.59.3:5060
> <http://sip:5216161079999@202.152.59.3:5060>
> <http://sip:5216161079999@202.152.59.3:5060>
> <http://sip:5216161079999@202.152.59.3:5060>
>
>
> 60.919007 202.152.59.3 -> 75.82.100.5 SIP Status: 200 OK
>
> 60.919730 75.82.100.5 -> 62.25.18.34 SIP Status: 200 OK
>
> 66.324643 202.152.59.3 -> 75.82.100.5 SIP Status: 500
> Internal Server Error
>
> 66.325256 75.82.100.5 -> 202.152.59.3 SIP Request: ACK
> sip:5216161079999 at 202.152.59.3
> <mailto:sip%3A5216161079999 at 202.152.59.3>
> <mailto:sip%3A5216161079999 at 202.152.59.3
> <mailto:sip%253A5216161079999 at 202.152.59.3>>
> <mailto:sip%3A5216161079999 at 202.152.59.3
> <mailto:sip%253A5216161079999 at 202.152.59.3>
> <mailto:sip%253A5216161079999 at 202.152.59.3
> <mailto:sip%25253A5216161079999 at 202.152.59.3>>>
>
>
>
> 66.326427 75.82.100.5 -> 62.25.18.34 SIP Status: 503
> Service Unavailable
>
> 66.796377 75.82.100.5 -> 62.25.18.34 SIP Status: 503
> Service Unavailable
>
> 67.797229 75.82.100.5 -> 62.25.18.34 SIP Status: 503
> Service Unavailable
>
> 69.798014 75.82.100.5 -> 62.25.18.34 SIP Status: 503
> Service Unavailable
>
> 74.689429 62.25.18.34 -> 75.82.100.5 SIP Request: CANCEL
> sip:5216161070241 at 75.82.100.5
> <mailto:sip%3A5216161070241 at 75.82.100.5>
> <mailto:sip%3A5216161070241 at 75.82.100.5
> <mailto:sip%253A5216161070241 at 75.82.100.5>>
> <mailto:sip%3A5216161070241 at 75.82.100.5
> <mailto:sip%253A5216161070241 at 75.82.100.5>
> <mailto:sip%253A5216161070241 at 75.82.100.5
> <mailto:sip%25253A5216161070241 at 75.82.100.5>>>;user=phone
>
>
>
> 74.690889 75.82.100.5 -> 62.25.18.34 SIP Status: 200
> canceling
>
>
> See, that 503 at the bottom doesn't make it through..
> Another bit of information. The "To:" header contains a
> prefix
> to the RURI. I don't care, I ignore the to header.. The 503
> reply ALSO has the To Header. The customer, is telling
> me that
> the To: header in the 503 reply needs to match the RURI. I
> believe that I shouldn't ever touch the To: or From:
> headers
> and that they should match exactly what he sent me.
>
>
> Any ideas what's going on here? Am I off base?
>
>
>
> ------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> <mailto:Users at lists.opensips.org>
> <mailto:Users at lists.opensips.org
> <mailto:Users at lists.opensips.org>>
>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
More information about the Users
mailing list