[Freeswitch-users] Handling REFER...

Anthony Minessale anthony.minessale at gmail.com
Thu Dec 17 14:06:04 PST 2009


The calls inherit the context from the parent, I think there is a var you
can set on the chan to pick what context to use in a transfer like
transfer_context or something grep the code for it

On Dec 17, 2009 1:07 PM, "Kristian Kielhofner" <
kristian.kielhofner at gmail.com> wrote:

Hello everyone,

I've got two profiles running: s2s and trunk.  The context for s2s is
defined as s2s-in.  The context for trunk is defined as trunk-in.
trunk is bound to 192.168.168.3.

recv 481 bytes from udp/[192.168.168.76]:5065 at 18:43:37.309706:
  ------------------------------------------------------------------------
  REFER sip:mod_sofia at 192.168.168.3:5060 SIP/2.0
  Via: SIP/2.0/UDP 192.168.168.76:5065;branch=z9hG4bK__7539073431157335561_9
  To: "NONAME" <sip:19415551212 at 192.168.168.3<sip%3A19415551212 at 192.168.168.3>
>;tag=BagvZeKSrj7yH
  From: <sip:9412848354 at 192.168.168.76:5065
;transport=udp>;tag=203332153_1430350929_10
  Call-ID: e505f332-65de-122d-d183-eb12ad0ec1ac
  CSeq: 2 REFER
  Max-Forwards: 70
  Refer-To: <sip:6463959906 at 192.168.168.3 <sip%3A6463959906 at 192.168.168.3>>
  Contact: <sip:ssp at 192.168.168.76:5065;transport=udp>
  Content-Length: 0

  ------------------------------------------------------------------------
send 592 bytes to udp/[192.168.168.76]:5065 at 18:43:37.316093:
  ------------------------------------------------------------------------
  SIP/2.0 202 Accepted
  Via: SIP/2.0/UDP 192.168.168.76:5065;branch=z9hG4bK__7539073431157335561_9
  From: <sip:9412848354 at 192.168.168.76:5065
;transport=udp>;tag=203332153_1430350929_10
  To: "NONAME" <sip:9415551212 at 192.168.168.3<sip%3A9415551212 at 192.168.168.3>
>;tag=BagvZeKSrj7yH
  Call-ID: e505f332-65de-122d-d183-eb12ad0ec1ac
  CSeq: 2 REFER
  Contact: <sip:mod_sofia at 192.168.168.3:5060>
  User-Agent: FreeSWITCH
  Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE,
SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO
  Supported: precondition, path, replaces
  Allow-Events: talk, refer
  Content-Length: 0

 FS routed this to the s2s-in context, even though it was sent to the
trunk profile.  Shouldn't it have ended up in trunk-in?  For the time
being I wrote some crazy dialplan for s2s-in to transfer the call to
trunk-in but I'm wondering what could be going on here.

--
Kristian Kielhofner
http://www.astlinux.org
http://blog.krisk.org
http://www.star2star.com
http://www.submityoursip.com
http://www.voalte.com

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20091217/dc6db1a8/attachment-0002.html 


More information about the FreeSWITCH-users mailing list