Well, I will have to rewrite a quite tricky part of my program. I will open an issue but I can't avoid rewrite. :-(
Regards, Gabor -----Original Message----- From: M. Ranganathan [mailto:[email protected]] Sent: 10 July 2009 15:37 To: Gabor Paller Cc: [email protected] Subject: Re: [sipx-users] UPDATE method and sipxbridge On Fri, Jul 10, 2009 at 10:25 AM, Gabor Paller<[email protected]> wrote: > " All the gateways that are I have used so use re-INVITE and not UPDATE > to update session parameters." > > Well, Cisco gateways support both (starting from IOS version 12.4M) and it is often more convenient to use UPDATE. I am sure somebody will soon run into this problem too. > Please reconfigure your gateway to use INVITE and thanks for making a note of this. Please open an issue and I'll put it up for consideration in the next release. Thanks Ranga > Regards, > Gabor > > -----Original Message----- > From: M. Ranganathan [mailto:[email protected]] > Sent: 10 July 2009 15:18 > To: Gabor Paller > Cc: [email protected] > Subject: Re: [sipx-users] UPDATE method and sipxbridge > > On Fri, Jul 10, 2009 at 2:52 AM, Gabor Paller<[email protected]> wrote: >> " It does not forward the UPDATE request as >> it is a back to back user agent and not a proxy server -- conceptually >> it is hiding the trunk provider from the pbx and vice versa." >> >> Do you mean that an UPDATE cannot get through sipxbridge? > > Yes that is what I meant. > > > All the gateways that are I have used so use re-INVITE and not UPDATE > to update session parameters. > > Please open a JIRA issue with specifics on what you would like to see > supported (include the details of the gateway or phone that is using > UPDATE ). > > Thanks. > >> >> " sipxBridge uses re-INVITE and not UPDATE for session timer." >> >> In this particular scenario, UPDATE is used to refresh the media >> descriptor of the session. It is not related to session timer. As >> described in RFC 3311: >> " Once a dialog >> is established, either early or confirmed, the caller can generate an >> UPDATE method that contains an SDP offer [3] for the purposes of >> updating the session. The response to the UPDATE method contains the >> answer. Similarly, once a dialog is established, the callee can send >> an UPDATE with an offer, and the caller places its answer in the 2xx >> to the UPDATE. " >> >> Re-INVITE cannot replace UPDATE in some scenarios, e.g. RFC 3960. >> >> -----Original Message----- >> From: M. Ranganathan [mailto:[email protected]] >> Sent: 10 July 2009 04:40 >> To: Gabor Paller >> Cc: [email protected] >> Subject: Re: [sipx-users] UPDATE method and sipxbridge >> >> On Thu, Jul 9, 2009 at 11:43 AM, Gabor Paller<[email protected]> >> wrote: >>> Hi, >>> >>> >>> >>> I have an authenticated SIP trunk, connected over sipxbridge. What I >> see >>> that if I send an UPDATE method to the trunk, sipxbridge immediately >>> responds with 405 Method not allowed, without consulting the trunk. >>> >>> >>> >>> I wonder, how sipxbridge detects that UPDATE methods are not allowed. >> >> >> When the request is sent to SipXbridge it simply responds with the >> methods that *it* supports. It does not forward the UPDATE request as >> it is a back to back user agent and not a proxy server -- conceptually >> it is hiding the trunk provider from the pbx and vice versa. >> >> sipxBridge uses re-INVITE and not UPDATE for session timer. >> >> Regards, >> >> Ranga >>> >>> >>> >>> Regards, >>> >>> Gabor >>> >>> Gabor Paller, Software Architect >>> OnRelay >>> >>> >>> >>> Elizabeth House | 39 York Road, London SE1 7NQ, UK | +44 (0) 207 902 >> 8151 | >>> [email protected] | www.onrelay.com >>> >>> >>> >>> OnRelay in the News: >>> >>> BT Trials OnRelay FMC Solution >>> >>> http://www.computing.co.uk/vnunet/news/2239084/bt-trial-fixed-mobile >>> >>> >>> >>> This electronic message transmission contains information from >> OnRelay, >>> Ltd., that may be confidential or privileged. The information is >> intended >>> solely for the recipient and use by any other party is not authorised. >> If >>> you are not the intended recipient, be aware that any disclosure, >> copying, >>> distribution or use of the contents of this information or any >> attachment, >>> is prohibited. If you have received this electronic transmission in >> error, >>> please notify us immediately by electronic mail ([email protected]) and >>> delete this message, along with any attachments, from your computer. >>> Registered in England No 04006093 | Registered Office 1st Floor, 236 >> Gray's >>> Inn Road, London WC1X 8HL >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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/ >>> >> >> >> >> -- >> M. Ranganathan >> > > > > -- > M. Ranganathan > -- M. Ranganathan _______________________________________________ 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/
