Re: [reSIProcate] Almost have Invite working, but....
As my previous answer for your question.
you should call it like this:
...................................................
sdp = new SdpContents(hfv, type); <---- But this is the problem for me.
sdp->checkParsed();
............................................
Because sdpArray is a local variable allocated on stack. On leave
this function, the memory will be released. So a invalid memory access
will ocured after your leave this function.
SdpContents class is a derived class of LazyParser class. only after
your called sdp->checkParsed(), its internal memory can be created for
sdp object on heap.
2005/12/7, John Draper <lists@xxxxxxxxxxxxxxxx>:
> Hi,
>
> INVITE sip:u97@xxxxxxxxxxxxx:5060 SIP/2.0
> To: <sip:u97@xxxxxxxxxxxxx:5060>
> From: <sip:u354@xxxxxxxxxxxxx:5060>;tag=4bf2b953
> Via: SIP/2.0/ ;branch=z9hG4bK-d87543-369f8d1d066b7118-1--d87543-;rport
> Call-ID: 4acdf1000d791cee@am9obi1kcmFwZXJzLWNvbXB1dGVyLmxvY2Fs
> CSeq: 1 INVITE
> Contact: <sip:u354>
> Max-Forwards: 70
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
> Content-Length: 0
>
> DEBUG | 1133949137 | SipPhone | RESIP |
> /Users/johndraper/Documents/SIP/Open_source/resiprocate-0.9.0-5019/resiprocate/os/BaseException.cxx:17
> | BaseException at
> /Users/johndraper/Documents/SIP/Open_source/resiprocate-0.9.0-5019/resiprocate/os/ParseBuffer.cxx:85
> /Users/johndraper/Documents/SIP/Open_source/resiprocate-0.9.0-5019/resiprocate/os/ParseBuffer.cxx:85,
> Parse failed expected 'o' in context: Contents <---- What does this
> mean?
>
> v=0[CRLF]
> ^[CRLF]
> **o=- 0 0 IN IP4 192.168.0.4 <----- Is it because this is wrong?
> **s=WhitePhone Mac
> **c=IN IP4 192.168.0.4
> **t=0 0
> **m=audio 10976 RTP/AVP 0 8 3 97 101
> **a=rtpmap:0 pcmu/8000
> **a=rtpmap:8 pcma/8000
> **a=rtpmap:3 gsm/8000
> **a=rtpmap:97 speex/8000
> **a=rtpmap:101 telephone-event/8000
> **a=fmtp:101 0-15
>
> Program aborts and crashes of course. But resip was generating this
> log. At least I'm getting this far. I just need to know what this means.
>
> The distant SIP server did NOT get the initial Invite request by the way.
> I also found out I don't have to send the OPTIONS command prior to
> INVITE for our server.
>
> Program received signal: "SIGABRT".
>
> Program crashed as usual in the parse part.
>
> Stack trace follows (if anyone cares).
>
> #4 0x00179450 in __cxa_throw at iostream:76
> #5 0x000a214c in resip::ParseBuffer::fail(char const*, unsigned,
> resip::Data const&) const at ParseBuffer.cxx:896
> #6 0x0009f38c in resip::ParseBuffer::skipChar(char) at ParseBuffer.cxx:85
> #7 0x000104f0 in
> resip::SdpContents::Session::Origin::parse(resip::ParseBuffer&) at
> SdpContents.cxx:267
> #8 0x000140f4 in
> resip::SdpContents::Session::parse(resip::ParseBuffer&) at
> SdpContents.cxx:955
> #9 0x0000fd40 in resip::SdpContents::parse(resip::ParseBuffer&) at
> SdpContents.cxx:181
> #10 0x0009da10 in resip::LazyParser::checkParsed() const at
> LazyParser.cxx:79
> #11 0x000a84ec in resip::Contents::exists(resip::HeaderBase const&)
> const at Contents.cxx:183
> #12 0x0007ca70 in
> resip::SipMessage::setContents(std::auto_ptr<resip::Contents>) at
> SipMessage.cxx:740
> #13 0x0007cd78 in resip::SipMessage::setContents(resip::Contents
> const*) at SipMessage.cxx:769
> #14 0x000efbd8 in
> resip::InviteSessionCreator::InviteSessionCreator(resip::DialogUsageManager&,
> resip::NameAddr const&, resip::UserProfile&, resip::SdpContents const*,
> resip::Handle<resip::ServerSubscription>) at InviteSessionCreator.cxx:30
> #15 0x000ef91c in
> resip::InviteSessionCreator::InviteSessionCreator(resip::DialogUsageManager&,
> resip::NameAddr const&, resip::UserProfile&, resip::SdpContents const*,
> resip::Handle<resip::ServerSubscription>) at InviteSessionCreator.cxx:13
> #16 0x000624d0 in
> resip::DialogUsageManager::makeInviteSession(resip::NameAddr const&,
> resip::SdpContents const*, resip::AppDialogSet*) at
> DialogUsageManager.cxx:423
> #17 0x0000a1cc in -[SipBridge makeCallTo:] at SipBridge.mm:296
>
> partial code that created the "sdp" record is below.
> called "Create_sdp" - see my earlier posting.
>
> // Make a "to" NameAddr
> NameAddr to(myDestURI);
>
> Data host(to.uri().host());
> const char *ipadr = [mBridge getMyIP];
>
> int result = sprintf(sdpstr, "v=0\n\
> o=0 0 IN IP4 %s\n\
> s=WhitePhone Mac\n\
> c=IN IP4 %s\n\
> t=0 0\n\
> m=audio 10976 RTP/AVP 0 8 3 97 101\n\
> a=rtpmap:0 pcmu/8000\n\
> a=rtpmap:8 pcma/8000\n\
> a=rtpmap:3 gsm/8000\n\
> a=rtpmap:97 speex/8000\n\
> a=rtpmap:101 telephone-event/8000\n\
> a=fmtp:101 0-15\n", ipadr, ipadr);
>
> txt = new Data(sdpstr);
>
> hfv = new HeaderFieldValue(txt->data(), txt->size());
> Mime type("application", "sdp");
> sdp = new SdpContents(hfv, type);
>
> Partial code that sent the invite is here... I commented out the OPTIONS
> send.
> Our sip server don't need it.
>
> // Create the SDP record with the IP I get from the InfoServer.
> myUAC->Create_sdp(myToCString);
>
> char *myRecipient = [recipient UTF8String];
> NameAddr toRecipient(myRecipient);
>
> if (!startedCallFlow) {
> startedCallFlow = true; // instance var
>
> // Kick off call flow by sending an OPTIONS request then an INVITE
> // request from the UAC to the UAS
> // Should probably add Allow, Accept, Accept-Encoding,
> Accept-Language and Supported
> // headers - but this is fine for testing/demonstration
>
> //cout << "UAC: Sending Options Request to UAS." << endl;
> //clientDum->send(clientDum->makeOutOfDialogRequest(*from,
> OPTIONS, new myAppDialogSet(*clientDum, Data("UAC(OPTIONS)"))));
>
> // Make an invitation Message, by asking the DUM to do it.
> cout << "UAC: Sending Invite Request to UAS." << endl;
> clientDum->send(clientDum->makeInviteSession(toRecipient,
> myUAC->sdp, new myAppDialogSet(*clientDum, "UAC(INVITE)")));
>
> }
>
> So, is it obvious to anyone what it is I'm doing wrong? And why the
> parser is gagging on my
> "sdp" record?
>
> This is the exact SDP record the Windows client has to send for the
> invite...
> Does the resip stack not like something about it? I know from sniffing
> the Windows application I'm porting from, that the Windows client
> sends this exact "sdp". Why is resip rejecting it?
>
> John
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>