On Wed, 2010-02-03 at 10:18 +0000, Sven Evensen wrote: > (Is there a mximum size of attachments? )
Yes - 60K > Our application uses REFER to transfer an external call (mobile) from > one internal user to another internal user > > When the REFER is sent to the Cisco GW, it responds with an INVITE > which looks a little different than the INVITE from the sipXBridge. > Some SIP trunks do not support REFER, therefore sipXBridge can be used > to convert the REFER to an INVITE. (In addition to handling NAT etc). > The whole issue is the From: field in the mentioned INVITE is > different in the Cisco case and in the sipXBridge case (ruining our > algorithm) > Cisco case : INVITE >From : 07795951717 (mobile), To: 8216 (internal > dest) > > sipXBridge : INVITE >From : 01225581810 (DDI of internal user) To: > 8216. > The scenario is as follows: > > A calls B, B answers > > Our appl. sends a REFER to transfer from A to C > > The REFER has From : A, To : B, Refer-To : C, Referred-By : A > > When using unmanaged GW (Cisco IOS GW), it replies with > INVITE From : B, To C > > sipXBridge replies with > INVITE From : A*, To C > A – 8116 (phantom user) > A* - 01225581810 (DDI of A) > B – 07795951717 (mobile) > C – 8216 (phantom user) > The question is: Is Cisco GW doing right or is sipXBridge doing right? > Or maybe both? Well... "right" is a slippery concept in this case. Most SIP specifications (including those for REFER and transfer) don't address what the behavior of a B2BUA in the path should be, so there are no well-defined rules. Just to check my understanding... What your application (which is A above and 10.226.226.241:5560 in your trace?) would like to see is that the INVITE for the call leg from transferee to transfer target have a >From header identifies the transferee (B or <sip:[email protected];user=phone>) , but what you're seeing is that the From header on that INVITE identifies the B2BUA (sip:01225581...@...) - correct? > Sorry, but it is extremely difficult to describe this scenario. > Attached is the merged.xml for this call. I've attached a cleaned-up and colorized version of your trace (you'll need a recent version of sipviewer to see the colors - you can get it from [1]). The original call is green on the inside and blue on the outside, and the transferred inside leg is red. I'm not sure that I have a real answer to your question, but here are some thoughts.... For the purposes of 'outside' signaling to the ITSP, sipXbridge is constrained to using the identity of the SIP trunk - ITSPs generally require this (which combination of From and P-Asserted-Identity headers are required by any given ITSP varies, but that's what all those annoying configuration switches are for). On the 'inside' call legs, sipXbridge is theoretically less constrained - it could construct its To/From headers based on the corresponding headers from the ITSP call legs, which (if I'm correct above) is what your application expects/needs. Obviously, that's not what it does now. What it is doing is using the same header that it used when it accepted the 'inside' call leg - it's not clear to me how your application could expect anything different (where does it get the expectation from?). It looks as though the point of your transfer is to move from one port to another, so I'm guessing that it's changing services. Relying on the >From header value to do any correlation for this change doesn't seem to me to be a very good choice - even aside from this scenario, there aren't any hard rules I'm aware of that require the transferee to keep the From header the same. A much more reliable approach might be to put a url parameter on the Refer-To url - that should then be delivered back to your transfer target in the request uri of the resulting INVITE. [1] http://wiki.sipfoundry.org/download/attachments/4260006/sipviewer-install.jar?version=1&modificationDate=1265200336524
transfer.xml.gz
Description: GNU Zip compressed data
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
