[OpenSIPS-Users] [Re: Routing problem with Record-Route]
mickael at winlux.fr
Fri Aug 31 21:18:49 CEST 2012
Yes,* CUSTOMER_DEVICE_SIP_DOMAIN *is insert to "domain" table in
Le 31/08/2012 15:48, Binan AL Halabi a écrit :
> Is *CUSTOMER_DEVICE_SIP_DOMAIN defined in opensips* ?
> --- On *Fri, 8/31/12, Kevin Mathy /<k.mathy at hexanet.fr>/* wrote:
> From: Kevin Mathy <k.mathy at hexanet.fr>
> Subject: Re: [OpenSIPS-Users] [Re: Routing problem with Record-Route]
> To: "Bogdan-Andrei Iancu" <bogdan at opensips.org>, "OpenSIPS users
> mailling list" <users at lists.opensips.org>
> Date: Friday, August 31, 2012, 5:53 AM
> Hi Bogdan,
> We've got some news about our problem with record-routes.
> In fact, it seems that if we change Contact header sent by
> customer's device, everything work fine. Explanations :
> Before, in all message sent by customer's device, particularly
> 200OK, Contact header was like *Contact:
> <sip:+333XXXXXXXX at CUSTOMER_DEVICE_SIP_DOMAIN>*
> In this situation, OpenSIPS was unable to route correctly ACK
> messages following this 200OK.
> Then, we've change the manner which Contact header is sent, and
> now it's like *Contact: <sip:+333XXXXXXXX at CUSTOMER_DEVICE_IP>*
> And in this situation, everything seems to be OK, all message,
> including ACK, are correctly routed.
> Further, we are sure that DNS resolution of CUSTOMER_SIP_DOMAIN
> returns exactly CUSTOMER_DEVICE_IP, so, it doesn't seems to be a
> DNS resolution problem...
> If it can help you !
> Thanks a lot,
> *Kevin MATHY*
> Téléphone : 03.26.79.30.05
> Web : www.hexanet.fr <http://www.hexanet.fr>
> Pour toute demande de support, merci de contacter le
> *03.51.08.42.07*, ou bien d'adresser un e-mail à
> *support at hexanet.fr </mc/compose?to=support at hexanet.fr>*
> 2012/8/29 <mickael at winlux.fr </mc/compose?to=mickael at winlux.fr>>
> Hi Bogdan,
> we will do this debug before end of week or begin of next week
> and we will
> send our results.
> > Hi Kevin,
> > This looks like OpenSIPS does not recognize the Route as its
> own IPs and
> > also seeing the next hop as a strict router.
> > To sort this out in the fastest way, see my prev request on
> the logs for
> > ACK processing (with the debug=6).
> > Regards,
> > Bogdan-Andrei Iancu
> > OpenSIPS Founder and Developer
> > http://www.opensips-solutions.com
> > On 08/28/2012 03:22 PM, Kevin Mathy wrote:
> >> Hi Bogdan,
> >> I'm working with Mickael about this problem, and we have some
> >> informations which may help you (and then help us ;-) ) :
> >> We have found that "loose_route" function modify the
> >> variable ($ru), as you can see below :
> >> ACK message comes from provider, with $ru =
> sip:+333XXXXXXXX at 184.108.40.206
> </mc/compose?to=sip%3A%2B333XXXXXXXX at 220.127.116.11>
> >> <mailto:sip%3A%2B333XXXXXXXX at 18.104.22.168
> </mc/compose?to=sip%253A%252B333XXXXXXXX at 22.214.171.124>>
> >> After, loose_route function is executed, and $ru become
> like $ru
> >> =
> >> The last $ru value results from a Route header
> >> For information, Record-route of previous message (200OK)
> is composed
> >> with two record-route in the same field, comma separated.
> >> Is Opensips 1.6.4 able to interpret this type of Record-route ?
> >> Is loose_route function using Route headers of previous
> >> (200OK before ACK) to route this message ? Or is it using
> only actual
> >> message's Route headers ?
> >> Thanks in advance,
> >> If you need further informations, feel free to ask us.
> >> Regards,
> >> *Kevin MATHY*
> >> *HEXANET*
> >> *
> >> --
> >> *
> >> Téléphone : 03.26.79.30.05
> >> Web : www.hexanet.fr <http://www.hexanet.fr>
> >> Pour toute demande de support, merci de contacter le
> >> ou bien d'adresser un e-mail à *support at hexanet.fr
> </mc/compose?to=support at hexanet.fr>
> >> <mailto:support at hexanet.fr </mc/compose?to=support at hexanet.fr>>
> -----Inline Attachment Follows-----
> Users mailing list
> Users at lists.opensips.org </mc/compose?to=Users at lists.opensips.org>
> Users mailing list
> Users at lists.opensips.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users