On 09/03/2011 05:53 PM, Sarat C. Vemuri wrote:
3.Using request_route_preset(“publicIP”)
The above “mostly” works. By that I mean, the INVITE transaction is
properly passed between internal UAS and carrier SBC and the call is
setup. However, further transactions (BYE/re-INVITE) etc do not work
properly. So, far-end hangups are not working etc.
So in other words, there is no interface to which Kamailio could be
bound on a network that both the UAC and the UAS have direct network
and transport-layer reachability to?
If I understand correctly, it sounds like the fundamental problem here
is that the Record-Route URI introduced by the proxy in handling the
initial INVITE request has to be conserved in all subsequent requests
and replies. It is a requirement to use the same route set in
sequential (in-dialog) requests such as reinvites or BYEs. It is also
mandatory for the UAS to copy the received Record-Route into the final
reply (i.e. 200 OK).
The problem is that you then have to choose the network address in the
Record-Route. If either the UAC or the UAS cannot directly reach it,
your problem arises.
Is this an accurate statement of the problem? I wanted to verify
before continuing.
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
