SIP allowed Parameters

Dear ALL,

My carrier send UPDATE message each 3600 sec , but whenever i receive this my Asterisk reply with " SIP/2.0 501 Method Not Implemented"
the default asterisk parameters are:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

how can i add the UPDATE !!! to these allowed parameter
can anyone point me to a useful link\document ,on where to explore more regarding these parameters?

thanks in advanced

Hussein

The current version can handle certain types of update, but you will need enable rpid_update for this to happen. It may well reject your ones for different reasons if you do that.

Apart from this, you will need to write a handle_request_update function, that handles the specific UPDATE requests sent by your peer. Actually adding it to the Allow line, once you can really handle it, should be easy.

Of course, a peer that can’t cope with method not implemented, in this case, is broken. If it is unable to cope there, should be a configuration option on it to stop it sending them.

Ideally, if you register with it, it should note that UPDATE is not allowed in the REGISTER, and not try to use it. However tolerating method not implemented is also reasonable.

Actually i am not uing the Rpid , instead i am using PPI

[quote=“david55”]
Apart from this, you will need to write a handle_request_update function, that handles the specific UPDATE requests sent by your peer. Actually adding it to the Allow line, once you can really handle it, should be easy.

Of course, a peer that can’t cope with method not implemented, in this case, is broken. If it is unable to cope there, should be a configuration option on it to stop it sending them.[/quote]

Can you please point me , on where to find \read about these “handle_request_update” or how to create them??

thanks again for the support

svn.digium.com/svn/asterisk/tags//channels/chan_sip.c

Actually I was rather suggesting that you had a non-trivial bit of programming to do, as there is no point in claiming that you can handle UPDATE if you don’t actually handle it. In fact, part of the problem is that the peer is ignoring the fact that it is being told you don’t support it.

Becaue of the support for UPDATE for called party updates, there probably already is a handle_request_update function. The problem is that it probably doesn’t handle the sort of UPDATE that your service provider is sending.

If your version doesn’t already have a handle_request_update, or similar, you will need to also add the code that recognizes incoming UPDATEs and routes them to that function.