Hi,
does anyone know of a SIP opensource stack that has been ported to Symbian and
supports multi-threading for applications? I am aware of PJSIP which has been
ported to Symbian, but does not support multi-threading for applications.
Any suggestions would be greatly appreciated.
thanks and be
Iñaki Baz Castillo wrote:
> Hi, in case a SIP message (i.e. MESSAGE text/plain) contains a very
> long line in the body (a long text with no line breaks), could it
> become a problem?
>
> Unfortunately I've seen some SIP ALG routers dropping SIP messages if
> they contain long lines in the messa
Hi, in case a SIP message (i.e. MESSAGE text/plain) contains a very
long line in the body (a long text with no line breaks), could it
become a problem?
Unfortunately I've seen some SIP ALG routers dropping SIP messages if
they contain long lines in the message body, but I expect that is an
issue i
Nitin Kapoor wrote:
> Thanks for your reply.
>
> I checked the RFC and noticed that it does not limit the codec #s in mline,
> but nor does it comment on infinite number of codecs support being
> mandatory.
>
> So could you please let me know whether it is mandatory to support them or
> not. Be
Nitin,
This is just a matter of personal opinion, but I think having that many
codecs offered on an m= line is ridiculous. I'd like to hear somebody give
justification for doing it :-)
Seriously, how in the world can one build an interoperable system with this
much clutter to dig through?
Thanks for your reply.
I checked the RFC and noticed that it does not limit the codec #s in mline,
but nor does it comment on infinite number of codecs support being
mandatory.
So could you please let me know whether it is mandatory to support them or
not. Because if my SBC is not supporting this
As per spec 2327 this is valid ! check fmt.
media-field = "m=" media space port ["/" integer]
space proto 1*(space fmt) CRLF
media = 1*(alpha-numeric)
;typically "audio", "video", "application"
This is valid, though I've never seen so many codecs on a single m= line.
Who can practically deal with this? ;-)
Paul
From: sip-boun...@ietf.org [mailto:sip-boun...@ietf.org] On Behalf Of Nitin
Kapoor
Sent: Wednesday, September 01, 2010 9:51 AM
To: sip-implementors@lists.cs.columbia.edu; s
It's allowed, though admittedly strange. None of the attributes for the second
m= line have any significance.
Paul
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> fred.madi...@gmx.net
>
Hi
I receive a re-INVITE for a switchover from G.711 to T.38 with the
following SDP:
v=0
o=ABC 1542876549 1542876550 IN IP4 W.X.Y.Z
s=abs
c=IN IP4 A.B.C.D
t=0 0
m=image 32603 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:256
a=T38FaxMax
Dear All,
I am facing the problem where one of source is sending bunch of RTP payload
in "mline", and because of that my MSX is stripping 2 codec from that line,
when its forwarding that OFFER to termination end.
This is the "mline" which i am getting from source:
*m=audio 6300 RTP/AVP 18 0 8 35
11 matches
Mail list logo
