M. Ranganathan wrote: > The problem is whether or not to forward Re-INVITE that I see from a UA. > > In sipxbridge, I maintain my own session timer with the iTSP (required) > > Many / most phones send OPTIONS for liveness testing. Then you have > park server that now wants to send Re-INVITE. What do you want the > bridge to do with it? How do I know it is a session timer and not a > re-negotiation attempt with the ITSP? Since I cant distinguish > between the two cases, I have to blindly forward it ( unless you want > some really ugly <do-not-forward-if-reinvite-is-from-park-server> > switch). > > Now I also need to forward Re-INVITE for reasons other than session > timer. There are genuine use cases for end to end codec renegotiation > - consider FAX and call transfer. So now I have a problem. How can I > distinguish between the two usages of it ( i.e. codec renegotiation > vs. liveness testing ) ? Since I cant in general do so, I have to > blindly forward the re-INVITE. > > If you really must insist on not using OPTIONS, I would lean towards > UPDATE rather than Re-INVITE. > > Ranga > >
Ok, so right now the park server is just using codec renegotiation as a keepalive, i.e. I wake up the park orbit every 5mins (time is configurable) and ask it to renegotiate its codecs. So, you should be able to treat this as just a regular codec-renegotiating re-INVITE. Arjun _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
