I haven't keep that configuration, but founded, in a log, a SDP created by a Cisco 2600 in IPIPGW configuration mode...
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* START of SDP multipart/mixed;boundary=uniqueBoundary Content-Length: 514 --uniqueBoundary Content-Type: application/sdp v=0 o=CiscoSystemsSIP-GW-UserAgent 3618 1606 IN IP4 X.X.X.X s=SIP Call c=IN IP4 X.X.X.X t=0 0 m=audio 18380 RTP/AVP 4 101 c=IN IP4 200.189.198.244 a=rtpmap:4 G723/8000 a=fmtp:4 bitrate=6.3;annexa=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11,16 a=ptime:30 a=silenceSupp:off - - - - --uniqueBoundary Content-Type: application/gtd Content-Disposition: signal;handling=optional CPG, PRN,isdn*,,QSIG*, --uniqueBoundary-- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* END of SDP I only changed the IP, all rest is SDP body. Sorry for the inconvinience... :( Edson >-----Original Message----- >From: Ovidiu Sas [mailto:[EMAIL PROTECTED] >Sent: sexta-feira, 10 de agosto de 2007 15:17 >To: Edson >Cc: Bogdan-Andrei Iancu; [email protected] >Subject: Re: [OpenSER-Devel] Request for comments: sdpparser: module >orintegrated into the core > >Hi Edson, > >Can you send me an AS5300 CISCO config that is generating multi-part body? > > >Regards, >Ovidiu Sas > >On 8/10/07, Edson <[EMAIL PROTECTED]> wrote: >> Hi, Ovidus... >> >> Just to let You know that multipart SDP are generated by Cisco GWs (at >least >> 3810 and 5300 models). I don't know there types, I'm not good in SDP, but >> seems to be one for codecs and other for facilities. >> >> If You whana a hand, maybe I can help You in this tests... >> >> Edson >> >> >-----Original Message----- >> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> >Behalf Of Ovidiu Sas >> >Sent: sexta-feira, 10 de agosto de 2007 11:39 >> >To: Bogdan-Andrei Iancu >> >Cc: [email protected] >> >Subject: Re: [OpenSER-Devel] Request for comments: sdpparser: module >> >orintegrated into the core >> > >> >Hi Bogdan, >> > >> >I think that multi-part body parsing should be part of the general >> >message parsing. >> >The SDP specific parser will be under ./parser/sdp >> >There's nothing preventing proper support for multi-part body. >> > >> >I don't have a SIP UA that generates multi-part body to test how it >> >will work ... >> > >> > >> >Regards, >> >Ovidiu Sas >> > >> >On 8/10/07, Bogdan-Andrei Iancu <[EMAIL PROTECTED]> wrote: >> >> Hi Ovidiu, >> >> >> >> are there any plans to support multi-part body? in case SDP in one on >> >> the parts..... >> >> >> >> Regards, >> >> Bogdan >> >> >> >> Ovidiu Sas wrote: >> >> > Hi Cesc, >> >> > >> >> > I just ported some existing parsing functions from the nathelper >> >> > module (just to minimize the impact to the other modules) and >enhance >> >> > them. The idea was to follow the openser generic parser. >> >> > >> >> > >> >> > Ovidiu >> >> > >> >> > On 8/8/07, Cesc Santa <[EMAIL PROTECTED]> wrote: >> >> > >> >> >> If I may have a say ... I would include this also in the core. And >as >> >> >> pointed by Bogdan, SDP is signalling also ... so I would not see it >so >> >bad >> >> >> having the parser functions in the core with the option of the >modules >> >> >> modifying the SDP. >> >> >> >> >> >> BTW, Ovidiiu ... in your email I read that you are creating the >parser >> >... >> >> >> from scratch? Would not it be a good idea to hunt for an already >> >existing >> >> >> SDP library and integrate it? >> >> >> >> >> >> Cesc >> >> >> >> >> >> >> >> >> On 8/8/07, Bogdan-Andrei Iancu <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >>> Hi Henning, >> >> >>> >> >> >>> SDP is also signalling part (for media) and we are evaluation >_only_ >> >> >>> parsing functions, not functions to manipulate and do SDP changes. >> >> >>> >> >> >>> currently there are 2 modules (nathelper and mediaproxy) parsing >SDP >> >and >> >> >>> there is an intense demand for other SDP related functionalities >> >(like >> >> >>> being able to investigate SDP from script, etc); so makes no sense >to >> >> >>> have n modules, each implementing a parser. >> >> >>> >> >> >>> We can have a parser in core and the modules will use it for >whatever >> >> >>> specific purposes. >> >> >>> >> >> >>> If you make the parser a module, it will be rather a library than >a >> >> >>> module and it will create extra inter-module dependencies that we >> >> >>> complicate thinks even more. >> >> >>> >> >> >>> Thanks and regards, >> >> >>> Bogdan >> >> >>> >> >> >>> Henning Westerholt wrote: >> >> >>> >> >> >>>> On Tuesday 31 July 2007, Bogdan-Andrei Iancu wrote: >> >> >>>> >> >> >>>> >> >> >>>>> Hi Ovidiu, >> >> >>>>> >> >> >>>>> If this will be a collection of functions for parsing, I see no >> >reason >> >> >>>>> for not trying to include them in core. But for such a decision, >> >more >> >> >>>>> info will be needed. >> >> >>>>> >> >> >>>>> >> >> >>>> Hello, >> >> >>>> >> >> >>>> integrating SDP parser functionality into the core would be the >> >start >> >> >>>> >> >> >> for >> >> >> >> >> >>>> providing more and more SDP and media stream related functions in >> >> >>>> >> >> >> OpenSER. >> >> >> >> >> >>>> I think we should try to stay on focus. >> >> >>>> >> >> >>>> - OpenSER is a multi-functional, multi-purpose SIP server: >router, >> >> >>>> >> >> >> switch, >> >> >> >> >> >>>> registrar, application server, redirect server, gateway, etc.. >> >> >>>> - OpenSER is only about signaling, but there are media adds-on >> >> >>>> >> >> >>>> (some quotes of a VON talk of Bogdan) >> >> >>>> >> >> >>>> In my opinion we're quite good in this area. But we've already >> >enough >> >> >>>> >> >> >> problems >> >> >> >> >> >>>> to support SIP and all the strange implementations out there. I >> >don't >> >> >>>> >> >> >> think >> >> >> >> >> >>>> its a good move to add to much SDP to our problem set. >> >> >>>> >> >> >>>> So i think a module implementation of a sdp parser would make >more >> >> >>>> >> >> >> sense. >> >> >> >> >> >>>> Cheers, >> >> >>>> >> >> >>>> Henning >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>> _______________________________________________ >> >> >>> Devel mailing list >> >> >>> [email protected] >> >> >>> http://openser.org/cgi-bin/mailman/listinfo/devel >> >> >>> >> >> >>> >> >> >> _______________________________________________ >> >> >> Devel mailing list >> >> >> [email protected] >> >> >> http://openser.org/cgi-bin/mailman/listinfo/devel >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> >> >> >> > >> >_______________________________________________ >> >Devel mailing list >> >[email protected] >> >http://openser.org/cgi-bin/mailman/listinfo/devel >> >> _______________________________________________ Devel mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/devel
