Call hold OxE 9.1 , 10.1.1 on Sip Trunks

[stefanc]

Hi !

After many hours of reading searching I have to reach out to you guys ...

Our customers must move from ISDN to SIP and we testing their systems, now we have some serious problems with services such as call hold.
I can not find any info on what RFC the OxE relies on regarding services such as call hold. Some info was referred and found in RFC 3725 (Third Party Control). But what RFC does Alcatel comply on regarding the services

Looking at the traces nothing is shown that a call hold is requested. Only a lot of new invite's that is not recognized at the operator's equipment.
I can not see the a=sendonly (RFC3264) or c= IN IP4=0.0.0.0 nor the o= , session version incr. by one ... that is referred in RFC 5359
The OxE 10.1.1 is stated to comply with RFC3264 (SDP) and in section 8.4 it tells us that the a= should go to sendonly. But this is not happening.
(Are there any settings in SIP that can change this behaviour ?)

So, can anyone out there explain with some simple traces so I have something to search for.

With hope for any suggestions ...

//Stefan

[alex]

Damn that SIP.
AFAIK no special RFC for call hold exists. Remember, SIP was developed not for the CO signalling, but for "sessions".
Used to be two methods for call hold (and transfer) - REFER and RE-INVITE. Basically it's just two different procedures to create new media and signalling paths for subscribers.
The method used depends on trunk type - SIP-ISDN and SIP-ABCF differs as long as I remember.
A lot of INVITES you see is exactly RE-INVITE procedure. As MOH in OXE resides in GD or INTIP OXE should establish another session with MOH source so it sends new INVITE (RE-INVITE) with another parameters.

Also there could be nothing sent on SIP signalling in case of Call Hold, e.g., in case of SBC use,

Ask your provider which method they support - REFER or RE-INVITE and why they ignore RE-INVITEs - as it shouldnt be ignored.

PS. "a=sendonly" is mainly for transmitting MOH but in theory you can transmit MOH with "a=sendrecv"

[stefanc]

Many thanks for your fast response ... I totally agree on the "damn that SIP" ... I really hate it , it is "protocol" of small cooked pieces that with hope an luck perhaps work out of the box with basic call .... I have programmed a lot on ISDN and it is really complex but is at least we have a standard (committee) with a apr. dokumentations. Further more, equipment has to conform to this standard. For SIP .......... the company that writes the most of the comments ... rules. The rest of this story is for another day ...


I have traced on both the 9.1 , and 10.1.1 and neither of pbx's sets the a=sendonly , recvonly... so I wonder how can any proxy know that a a hold is requested, a normal invite with tags is just a re-invite that resets the sessions timers .... am i right ? and for Call Hold the "signaling" parameter is just
the a= field in the SDP, so if the a=sendrecv and issue a re-invite , the result is just ==>> Reset session timers ....

I admit all days in the week that my knowledge of SIP is very thin (as it seems) but the Call Hold issue has become a really pain in the ass.

ps. I've looked at into lot of TC's,TG's but nothing ..... ds.

Regards // Stefan

[haroun]

hi
r9.1 HERE , and i confirm that oxe doesn't sent the necessary for call on hold , but in the other direction the CO send them

[alex]

I have traced on both the 9.1 , and 10.1.1 and neither of pbx's sets the a=sendonly , recvonly... so I wonder how can any proxy know that a a hold is requested, a normal invite with tags is just a re-invite that resets the sessions timers .... am i right ? and for Call Hold the "signaling" parameter is just
the a= field in the SDP, so if the a=sendrecv and issue a re-invite , the result is just ==>> Reset session timers ....
Regards // Stefan

Actually if you initiating Call Hold you could do it internally without sending any info to the SIP trunk.
Imagine analog or digital extension is calling on SIP trunk. Already all the media goes thru GD/INTIP - so then you switch to the MOH there is no need to send INVITE as nothing would be changed. But its just a theory.

In practice, I checked some traces and see that in case of putting on-hold, second INVITE (for sending MOH) is using the same Call-ID as first INVITE so UAS on the other side knows that its the same call but that media parameters would change.

[stefanc]

Hi
Many thanks haroun for your input..really appreciate this ... Do you know how the 9.1 or 10.1.1 indicate Call Hold instead. Is it in o= field by increasing the session version no by one ... ? ... or ... is there any newer release that correctly handles Call Hold.. (rel 11,12 etc ...)

[sadim]

You should check the external gw configuration.
I do not know if the parameter exists in all versions, but there is a parameter that if set to yes, allows to send on the reinvite the SDP.
I think the parameter is send reinvite with SDP.

[stefanc]

Hi !

For your info. Rel 11.2 doesnt change the a=sendrecv" to "a=sendonly either

Is there any one out there that got this call hold working against an operator via extern sip trunk with an OxE release below 12.

/S

[stefanc]

... some more interesting news on the matter, i've hooked up an snom sipphone to the oxe. did a local call to the sipphone , pressed the call park on the alcatelphone and did see that the phone send a=sendonly to the snom in the trace. Make'd a new call, now via siptrink bounced via extern gw and a operator. Pressed call park ... no sendonly was show in the trace just sendrecv I wonder now ... the trunk is set up as SIP ISDN shall it be SIP ABCF ... i'm totally lost ....,

[stefanc]

Hi !
Some more info ...

After some reprogramming of our SipProxy we found out that OxE doesn't send a=sendrecv" or "a=sendonly it just sends re-invite and let the rtp just flows on. Eg. it switches the endpoints of the stream to moh , tones... , furthermore Park/hold - retrieve doesn't seems to work. (no re-invite is sent in off-park retrieve call) but answer - transfer and similar things works.