Juan Carlos Castro y Castro wrote:
I have a scenario in which an OpenSER machine distributes load among several Asterisk machines for outgoing PSTN. I use an external program which I call through exec_dset() to select which server a call goes to. I use record_route().
All calls are completed OK, but when I dial from some SIP user-agents and hang up from the caller side, OpenSER gets crazy and doesn't know where to route the BYE to. Here's the reason:
Good scenario:
- I make a call to 5551234@mydomain
- OpenSER calls exec_dset, which turns it into
providercode#5551234@chosenserver
- Call is answered
- I hang up
- My UA sends a BYE like this: "BYE
sip:providercode#5551234@chosenserver SIP/2.0"
- I get an OK back, all is well.
(Sometimes the # in the uri above is sent as %23, but it works either
way)
Bad scenario:
- I make a call to 5551234@mydomain
- OpenSER calls exec_dset, which turns it into
providercode#5551234@chosenserver
- Call is answered
- I hang up
- My UA sends a BYE like this: "BYE sip:5551234@mydomain SIP/2.0"
- My openser.cfg doesn't know how to handle that and I get a "Loop
Detected" back. The destination never gets a hangup signal.
Is the second UA from the "bad" scenario disrespecting the RFC? Do I have any recourse to route a BYE that comes like that to the right Asterisk server?
Hi, Juan!
If called UA use 'providercode#5551234@chosenserver' as it own Contact-header then calling UA must use it to construct R-URI for BYE request.
But I think that called party still use '5551234@mydomain' as Contact-header. So you must route BYE request by the same way as INVITE request.
-- CU, Victor Gamov