Re: 答复: [reSIProcate] SDP Contents not getting created.....
FCG ZHAO Hongbin wrote:
>hi,
> the sdpstr that you defined is not correct. You should define it like this:
>--------------------------------------------------------------------------------------------------------
>int result = sprintf(sdpstr,
> "v=0\r\no= 0 0 IN IP4 %s\r\ns=WhitePhone Mac\r\nc=IN IP4
> %s\r\nt=0 0\r\nm=audio 10976 RTP/AVP 0 8 3 97 101\r\na=rtpmap:0
> pcmu/8000\r\na=rtpmap:8 pcma/8000\r\na=rtpmap:3 gsm/8000\r\na=rtpmap:97
> speex/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-15\r\n",
> ipadr, ipadr);
>---------------------------------------------------------------------------------------------------------------------------------------
>Note that there two difference between the above code and your code are:
>1.All content are written in the same line. if you write them in different
>line, just as shown in your code, some "tab" character may be inserted between
>different line. So the resiprocate will get an error and crashed.
>2. After the line 'o=' , there must be a spcace or source name, such as :"o= 0
>0 IN IP4 192.168.1.10" , "o=abc 0 0 IN IP4 192.168.1.10" or "o=- 0 0 IN IP4
>192.168.1.10" (may this is the main reason of your problem)
>
>
I already discovered that. You are right, but is was hard to read, so I
just left shifted the lines to start on Col 0 because readability is
more important to me. Unfortunately, I never got this message in time to
avoid a complete code walk-through to find the problem. This was because
the chinese character in the subject line caused the message to fall
outside the "sort group" and I never got this message. It wasn't until
after I went looking through my spam mail, was it found. My spam filter
filters out Chinese characters, because I never expect to get messages
in chinese, and ALL of it is spam. I'm more aware, now that there are
Chinese members to this list. I still don't have a need to block Chinese
IP blocks...
By the way, I notice your mailer inserts some Chinese character at the
start of my subject line, making it all but impossible for be to
"filter" my list mail from resip. My filter sorts it by subject line,
and the resip list maintainers always encourage people not to change
this. Because your mail was not picked up right away, I didn't get it
until after I spent long hour analysing this problem. With that said,
when you post replies to list mail, please be sure your mailer doesn't
insert 答复 in front of the subject line. I get more then 20,000 list
mails per day, it is virtually impossible for me to manage my resip mail
if I cannot "filter" it. This is why they put Re: [reSIProcate]. Most
mailers are programmed to ignore the "Re: " part of the message when
they sort it.
>
>By the way,
>----------------------------------
>sdp->checkParsed();
>----------------------
>this method should also be call in your function . or a crashed will occur. I
>have given the reason in my previous answer.
>
>
Thanx to this function, it helped me a lot, because it's a sort of
"sanity" check. I eventually found the problem.
By the way, one problem I posted last night, was one where I want to
send my Invite request to a server that's DIFFERENT then the server IP
address of the resolved recipient name in my destination URI.
I did find this... by chasing through the source code (using source
level debugger), I was able to find it... I hope it isn't throught of as
a most disgusting hack, but it worked... First, a definition of the
problem...
I have a URI: sip:testing@xxxxxxxxxxxxxx
When using resip, it goes out and tries to resolve "whitephone.com" into
an IP address, but this IP
address is NOT the same as the SIP server box.... So, MY solution to the
problem was figured out when
I used the source level debugger to break when I came to a piece if code
I suspected of resolving the
"whitephone.com"... the code is from "DnsResult.cxx". And thankfully, it
was named appropriatly so
I could find it without a lot of knowledge of the source code.
void
DnsResult::lookup(const Uri& uri)
{
DebugLog (<< "DnsResult::lookup " << uri);
//assert(uri.scheme() == Symbols::Sips || uri.scheme() == Symbols::Sip);
mSips = (uri.scheme() == Symbols::Sips);
mTarget = (!mSips && uri.exists(p_maddr)) ? uri.param(p_maddr) : uri.host();
mSrvKey = Symbols::UNDERSCORE + uri.scheme().substr(0,
uri.scheme().size()) + Symbols::DOT;
WELL: looks like the decision on which server is decided by whats in the
uri.param(p_maddr). It
didn't take me long to understand that mTarget must be the target
server. Again, thanks to reasonable
naming conventions. That's not to say ALL are.
So, in my "sdp" creator code, I did...
to.param(p_maddr) = "213.167.79.25";
Of course I didn't hard code it this way, other then to just test the
concept, and Yes indeed, it
was accessing the right server.
Is this the right approach to this problem? Is there a better way? I
notice the "to" field having
data "tag" after it... IE: To:
<sip:u6006@xxxxxxxxxxxxxx>;tag=59ceb4b014da46a9a6df4ff1b6fa002d
Is it my understaning that this is somehow converted to Base64 or some
other conversion? With more
then 250 pages of RFC to read, I haven't come across any info on this in
the RFC, but I suspect it's
in there... anyone know the main heading it's in?
Now I still have to figure out why it's crashing after the Invite is
sent... I'm not there yet folks, but
getting closer by the minute. :-)
John