[asterisk-dev] Supported SIP requests

[Vadim Lebedev]

Olle E Johansson wrote:

>
> 20 okt 2007 kl. 18.51 skrev Vadim Lebedev:
>
>>
>>
>> Olle E Johansson wrote:
>>
>>>
>>>>
>>>> Vadim
>>>>
>>>>> On 10/19/07, Vadim Lebedev <vadim at mbdsys.com> wrote:
>>>>>
>>>>>> Hello, Unless i'm missing suomtehing, believe that   
>>>>>> ALLOWED_METHODS #define in chan_sip.c should include MESSAGE  
>>>>>> and  INFO requests. Thanks Vadim
>>>>>
>>>>>
>>>
>>> INFO should propably only be included if we have video or DTMF/ 
>>> INFO  turned on.
>>>
>>> MESSAGE is something we only support during a call, so I've been   
>>> hesitating to turn it on until we
>>> have complete support. It's kind of shaky today. We send it, but   
>>> doesn't handle receiving it properly.
>>> And we don't check if the other party supports it either...
>>>
>>
>> Hi Ole,
>>
>> Actually the MESSAGE inside a dialog (RFC 3428) seems to be working  
>> pretty well in Asterisk (especially with recent patches mentionned in:
>> http://bugs.digium.com/view.php?id=11010)
>>
>> One improvement i'm thinking of, is adding support to Content-Type  
>> different from "text/plain"....
>
>
> Well, the internal message frame is now UTF-8, so to do that, we have  
> to declare new attributes to the
> text message. What kind of media types are you thinking of?
>
Initially i was thinking about text/html  but now i'm thinking about
something more generic.....

My idea is to implement a table which stores various content types,
and to store an index to the corresponding  entry in the
ast_frame.subclass
(with index 0 is reserverd for "text/plain"  for backwards compatibility)

This way relaying AST_FRAME_TEXT frames between 2 sip channels will work
perfectly well.

This can of course pose problems when relaying non text/plain frames to
the channel which supports only text/plain content type.
So i'm planning to add   optional can_relay(ast_channel *ac,
ast_frame *f)  method to the technology drivers to implement early
reject.



What do you think?

Thanks
Vadim

>